I am currently pursuing improved build functionality for static
libraries. One of the issues with static libraries are name collisions,
which led me back to an old discussion about which symbols are exported
from Hotspot, and how this is achieved. A long discussion is available
in JDK-8017234 [1], which was created in 2013 and has been on the back
burner ever since, coming back to life every now and then.
There are basically two different problems here. They are both distinct
and interrelated, and we likely need to solve both in tandem.
The first problem is how Hotspot should say which symbols (functions)
that should be exported from libjvm.so. The historical, and still used,
system is to have a mapfile. In the "new" (not so new anymore) build
system, this was simplified to a list of function names in
make/data/hotspot-symbols, from which a mapfile is built.
This is in contrast with how all other libraries in the JDK are built,
and also with modern best practices. A better approach would be to
annotate the functions that should be exported in the source code. In
fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but
this is currently not used in the compilation of Hotspot.
The second problem is that in addition to these explicitly exported
functions, we also export basically all other functions as well in
Hotspot. (So currently we could basically just forgo this complicated
machinery and just export everything by default...)
The reason for this seem somewhat unclear. The specifics are probably
forever lost in the mists of time past, but the essential point is that
these symbols are needed for SA to do it's job.
So what we do is that we list all symbols in hotspot after compiling
(but before linking), and selects some (most, I think) of them using
regexp patterns, and add these to the mapfile.
As long as we're doing this, we cannot stop using a mapfile, and we're
stuck from progressing on point 1.
My takeaway from the discussions is that we are most likely exporting a
way too broad set of symbols to SA. It seems likely that this set can be
drastically cut down. Actually getting an understanding of exactly which
symbols SA need seem like a very good first step.
So, is this a journey anyone would be interested in embarkering on? I
will help as much as I can from a build PoV, but I have no clue
whatsoever about what SA needs.
/Magnus
[1] https://bugs.openjdk.org/browse/JDK-8017234
