Hotspot symbol visibility

[Magnus Ihse Bursie]

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