We are compiling WebKit with -fvisibility=hidden (background: http://gcc.gnu.org/wiki/Visibility), and that's great. Hidden symbols can be resolved statically at link-time, causing no dynamic-linker overhead at runtime. On the other hand, symbols that are exported (those with default visibility) are subject to ELF symbol interposition rules, and so all accesses to them have to go through an indirection. Public visibility is of course the right thing to do for symbols that are actually public. Public visibility for private symbols creates maintenance problems, if clients use private symbols but it still happens to work. Public visibility for private symbols also has a runtime cost: the cost when dynamically linking the library, and the indirection for further accesses. Unfortunately, since we started to compile WTF and JSC as separate libraries (the first as a libtool helper lib only present at build-time, the second as a shared library), we have not been compiling them with -fvisibility=hidden. That means we've been experiencing the aforementioned problems for all symbols defined by WTF and JSC. This needs to be fixed.
(In reply to comment #0) > Unfortunately, since we started to compile WTF and JSC as separate libraries (the first as a libtool helper lib only present at build-time, the second as a shared library), we have not been compiling them with -fvisibility=hidden. That means we've been experiencing the aforementioned problems for all symbols defined by WTF and JSC. > > This needs to be fixed. I agree this would be nice to have. Does JSC use annotations for classes and functions that are used in WebCore now or would we need to maintain an export list like we do for WebKit and WebCore?
> Does JSC use annotations for classes and functions that are used in WebCore now I don't think so, no. > or would we need to maintain an export list like we do for WebKit and WebCore? There are other options, no? One would be to only export public API from libjavascriptcore -- the C API, I guess. You'd have to build separate libjsc and libwebkit, but the benefits might outweigh the disadvantages.
I think we should build libjsc into libwebkitgtk and a separate libjsc; the only problem I can think of is what would happen if a process links to both libwebkitgtk and libjsc in this case? We would still need to enforce same version to make it work, I imagine?
(In reply to comment #3) > I think we should build libjsc into libwebkitgtk and a separate libjsc; the only problem I can think of is what would happen if a process links to both libwebkitgtk and libjsc in this case? We would still need to enforce same version to make it work, I imagine? I worry what might happen if, for instance, a proxy resolver links against an older version of libjavascriptcore for autoproxy resolution and then some application uses libwebkitgtk and the proxy resolver library.
(In reply to comment #4) > I worry what might happen if, for instance, a proxy resolver links against an older version of libjavascriptcore for autoproxy resolution and then some application uses libwebkitgtk and the proxy resolver library. Which is to say that a symbol list seems less prone to problems in the future with the headache of a larger maintenance burden. I wonder if we could autogenerate our symbols list based on the one used by the Mac port.
That's exactly the problematic case I had in mind, Martin. Enforcing the same version would be suboptimal, but is a practical solution. If we could generate the symbols file, that'd be better, but we'd still have a performance hit. Would it improve the javascript execution time, though?
(In reply to comment #6) > That's exactly the problematic case I had in mind, Martin. Enforcing the same version would be suboptimal, but is a practical solution. If we could generate the symbols file, that'd be better, but we'd still have a performance hit. Would it improve the javascript execution time, though? I'm curious how the Mac port handles this situation. I see a .order file for JavaScriptCore (which I assume is the symbol list for Windows), but not a .exp file for Mac.