With modern compilers, we can use compiler directives (such as
_attribute__((visibility("default"))), or __declspec(dllexport)) to
control symbol visibility, directly in the source code. This has
historically not been present on all compilers, so we had to resort
to using mapfiles (also known as linker scripts).
This is no longer the case. Now all compilers we use support symbol
visibility directives, in one form or another. We should start using
this. Since this has been the only way to control symbol visibility
on Windows, for most of the shared code, we already have proper
JNIEXPORT decorations in place.
If we fix the remaining platform-specific files to have proper
JNIEXPORT tagging, then we can finally get rid of mapfiles.
This fix removed mapfiles for all JDK libraries. It does not touch
hotspot libraries nor JDK executables; they will have to wait for a
future fix -- this was complex enough. This change will not have any
impact on macosx, since we do not use mapfiles there, but instead
export all symbols. (This is not a good idea, but I'll address that
separately.) This change will also have a minimal impact on Windows.
The only reason Windows is impacted at all, is that some changes
needed by Solaris and Linux were simpler to fix for all platforms.
I have strived for this change to have no impact on the actual
generated code. Unfortunately, this was not possible to fully
achieve. I do not believe that these changes will have any actual
impact on the product, though. I will present the differences more in
detail further down. Those who are not interested can probably skip
that.
The patch has passed tier1 testing and is currently running tier2 and
tier3. Since the running code is more or less (see caveat below)
unmodified, I don't expect any testing issues.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
Details on changes:
Most of the source code changes are (unsurprisingly) in java.base and
java.desktop. Remaining changes are in jdk.crypto.ucrypto,
jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
Source code changes does almost to 100% consists in decorating an
exported function with JNIEXPORT. I have also followed the
long-standing convention of adding JNICALL. This is a no-op on
non-Windows platforms, so for most of the changes this is purely
cosmetic (and possibly adding in robustness, should the function ever
be used on Windows in the future). I have also followed the stylistic
convention of putting "JNIEXPORT <return type> JNICALL" on a separate
line. For some functions, however, this might cause a change in
calling convention on Windows. Since this can not apply to exported
functions on Windows (otherwise they would already have had
JNIEXPORT), I do not think this matters anything.
A few libraries did not have a mapfile, on Linux and/or Solaris. This
actually meant that all symbols were exported. It is highly unclear
if this was known and intended by the original make rule writer. I
have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these
libraries. Hopefully, we can remove this flag and fix proper exported
symbols in the future.
I have run the complete build using COMPARE_BUILD, and made a
thourough analysis of the differences for Linux and Solaris. All
native libraries have symbol differences, but most of them are
trivial and/or harmless. As a result, most libraries have disasm
differences as well, but these too seem trivial and harmless. The
differences in symbols that are common to all libraries include:
* Internal symbols such as __bss_start, _edata, _end and _fini are
now global. (They are imported as such from the compiler
libraries/archives, and we have no linker script to override this
behavior).
* The versioning tag SUNWprivate_1.1 is not included, and thus
neither the .gnu.version_d symbol.
* There are a few differences in the symbol and/or mangling of some
local functions. I'm not sure what's causing this,
but it's unlikely to have any effect on the product.
Another common source for change in symbols is due to previous
platform differences. For instance, if we had "JNIEXPORT int JNICALL
do_foo() { ... }", but do_foo was not in the mapfile, the symbol was
exported on Windows but not on Linux and Solaris. (Presumable since
it was not needed there, even though it was compiled for those
platforms as well.) Now, with the mapfiles gone, do_foo() will be
exported on all platforms. And contrary, functions that are compiled
on all platforms, and were exported in mapfiles, but now have gotten
an JNIEXPORT decoration, will now be visible even on Windows. (This
accounts for half of the noticed symbol differences on Windows.) I
could have made the JNIEXPORT conditional on OS, but I didn't think
the mess in source code were worth the keeping of binary confidence
with the old build.
A third common source for change in symbols is due to exported
functions "leaking" across library borders. For instance, some
functions in java.desktop is compiled in both libawt_xawt and
libawt_headless, but they were previously only included in the
mapfile for one of these libraries. Now, since the visibility is
determined by the source code itself, it gets exported in both
libraries. A variant of this is when a library depends on another JDK
library, and includes the header file from that other library, which
in turn declares a function as JNIEXPORT. This will cause the
including library to also export the function. This accounts for the
other half of the changes on Windows. A typical example of this is
that multiple libraries now re-export hotspot symbols from libjvm.so,
like jio_fprintf. (I have not listed the libjvm re-exports below.)
Note that Java_java_io_FileOutputStream_close0 in
java.base/unix/native/libjava/FileOutputStream_md.c is no longer
exported,
and can probably be removed.
Here is a detailed table showing and accounting for all the remaining
differences found on Linux and Solaris:
java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0
is now also exported on unix platforms due to JNIEXPORT.
java.base/jspawnlauncher: On solaris, we also include
libjava/childproc.o, which
now exports less functions than it used to (it used to export all
functions, now it is compiled with visibility=hidden).
java.base/java(w).exe: Is now also exporting the following symbols
due to added JNIEXPORT in libjli on Windows:
(Yes, executables can export symbols on Windows. Confusing, I know.)
JLI_AddArgsFromEnvVar
JLI_CmdToArgs
JLI_GetAppArgIndex
JLI_GetStdArgc
JLI_GetStdArgs
JLI_InitArgProcessing
JLI_Launch
JLI_List_add
JLI_List_new
JLI_ManifestIterate
JLI_MemAlloc
JLI_MemFree
JLI_PreprocessArg
JLI_ReportErrorMessage
JLI_ReportErrorMessageSys
JLI_ReportExceptionDescription
JLI_ReportMessage
JLI_SetTraceLauncher
JLI_StringDup
java.desktop:/libawt_xawt: The following symbols are now also
exported on linux and solaris due to JNIEXPORT:
awt_DrawingSurface_FreeDrawingSurfaceInfo
awt_DrawingSurface_GetDrawingSurfaceInfo
awt_DrawingSurface_Lock
awt_DrawingSurface_Unlock
awt_GetColor
The following symbols are now also exported on linux and solaris due
to JNIEXPORT (they were previously
exported only in libawt):
Java_sun_awt_DebugSettings_setCTracingOn__Z
Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
Java_sun_awt_X11GraphicsConfig_getNumColors
java.desktop:/libawt_headless: The following symbols are now also
exported due to JNIEXPORT (they were previously
exported only in libawt_xawt and/or libawt):
Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
X11SurfaceData_GetOps
java.desktop/libawt: The following symbols are now also exported on
Windows, due to added
JNIEXPORT:
SurfaceData_InitOps
mul8table
div8table
doDrawPath
doFillPath
g_CMpDataID
initInverseGrayLut
make_dither_arrays
make_uns_ordered_dither_array
path2DFloatCoordsID
path2DNumTypesID
path2DTypesID
path2DWindingRuleID
sg2dStrokeHintID
std_img_oda_blue
std_img_oda_green
std_img_oda_red
std_odas_computed
sunHints_INTVAL_STROKE_PURE
java.desktop/libawt on solaris:
A number of "#pragma weak" directives was previously overridden by
the mapfile.
Now these directives are respected, so these symbols are now weak
instead of local:
ByteGrayToIntArgbPreConvert_F
ByteGrayToIntArgbPreScaleConvert_F
IntArgbBmToFourByteAbgrPreScaleXparOver_F
IntArgbToIntRgbXorBlit_F
IntBgrToIntBgrAlphaMaskBlit_F
java.desktop/libawt on solaris: These are now also exported due to
JNIEXPORT in libmlib_image.
j2d_mlib_ImageCreate
j2d_mlib_ImageCreateStruct
j2d_mlib_ImageDelete
java.desktop/libawt on solaris: This is now also exported due to
JNIEXPORT:
GrPrim_CompGetXorColor
SurfaceData_GetOpsNoSetup
SurfaceData_IntersectBoundsXYWH
SurfaceData_SetOps
Transform_GetInfo
Transform_transform
java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and
solaris due to JNIEXPORT.
libspashscreen also had JNIEXPORT (actually a pure
_declspec(dllexport)) but no JNICALL, which I added as
a part of converting to JNIEXPORT. The same goes for libmlib_image .
jdk.sctp/libsctp: handleSocketError is now exported on linux and
solaris due to JNIEXPORT in libnio.
java.instrument:/libinstrument: Agent_OnUnload is now also exported
on linux and solaris platforms due to JNIEXPORT.
JLI_ManifestIterate is now also exported on Windows, due to added
JNIEXPORT in libjli.
jdk.management/libmanagement_ext:
Java_com_sun_management_internal_Flag_setDoubleValue is now also
exported on linux and solaris platforms due to JNIEXPORT.
/Magnus
