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