On 10/10/17 2:29 AM, Peter Levart wrote:
On 10/09/2017 10:17 PM, mandy chung wrote:
David, Peter, Alan
The VM has a fast path to search the symbol from libjava.so first for
bootstrap loader. That was the case I mostly concern about
performance and it's not impacted by this change. Also I consulted
with Claes on the performance impact. I took your suggestion and
made systemNativeLibraries and nativeLibraries volatile.
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.04
Looks good now. Just one question (for a possible follow-up future
optimization):
2674 private static long findNative(ClassLoader loader, String name) {
2675 Map<String, NativeLibrary> libs =
2676 loader != null ? loader.nativeLibraries() :
systemNativeLibraries();
2677 if (libs.isEmpty())
2678 return 0;
2679
2680 // the native libraries map may be updated in another thread
2681 // when a native library is being loaded. No symbol will be
2682 // searched from it yet.
2683 for (NativeLibrary lib : libs.values()) {
2684 long entry = lib.findEntry(name);
2685 if (entry != 0) return entry;
2686 }
2687 return 0;
2688 }
Now that (system)nativeLibraries is a Map, is it still necessary to
iterate it and call lib.findEntry(name) on each NativeLibrary until
the one that returns a non-zero entry or would it be semantically
equivalent to 1st look-up the Map by the 'name' key to get the correct
NativeLibrary?
The name parameter is the symbol name but not the library name. It's
confusing and therefore I renamed NativeLibrary::find to
NativeLibrary::findEntry. I could rename the name parameter to
entryName to make it clearer.
Mandy
