During the investigation of why we need both, linker export maps and -fvisibilty=hidden/__attribute__((visibility("default"))) (see http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012426.html) I found out that vtable symbols arn't exported any more at all if we are using GCC 4.3 and later, even if they are listed in the export maps.

The question is now if these vtable symbols are really needed by the serviceability agent SA (in which case we should find another way of exporting them) or not (in which case we should simply drop the magic which generates the vtable symbols in the map files (i.e. build_vm_def.sh) from the build).

Here some more details:

The vtable symbols are defined as weak symbols in the object files like so:

0000000000000000 V _ZTV10ArrayKlass

If such an object file will be linked with gcc 4.1.2 without map file
into the libjvm.so, the symbol would turn into a local data object
like so:

0000000000e37160 d _ZTV10ArrayKlass

However, if we use a map file which specifies that the symbol
'_ZTV10ArrayKlass' should be exported, the libjvm.so will contain the
following, global symbol:

0000000001423240 D _ZTV10arrayKlass

Now I think this is the expected result of the whole dynamic map-file
generation process. However, with gcc 4.3 and later, there's no
difference if the corresponding vtable symbol is mentioned in the
export map or not. The resulting libjvm.so always only contains a
local data object (just use 'nm --defined-only --extern-only
libjvm.so' to check).