On 10/9/17 3:47 AM, Peter Levart wrote:
On 10/09/2017 10:20 AM, Alan Bateman wrote:
On 06/10/2017 20:37, mandy chung wrote:
:
The native libraries map is now created lazily with
synchronization. I keep the lazy initialization that will save to
create a CHM as many custom class loaders don't have native code. I
think it's a good saving. In addition, if we iniitialize the
static systemNativeLibraries at <clinit> time, it may want to avoid
using CHM as it changes the class initialization order.
Alternatively change nativeLibraries and systemNativeLibraries to
volatile so the synchronization is only needed to initialize them.
Otherwise this version (webrev.03) looks good to me.
-Alan
Yes Mandy, you could use volatile fields + double checked locking for
initialization.
Since this might affect JNI binding, I have avoided changing it to
volatile in this patch until we get some performance number (I might be
overly conversative). I prefer to follow up this together in the lock
cleanup RFE that David suggests.
In addition, the initializers to 'null' value are not needed / are a
waste of instructions (the default is guaranteed by JLS):
2695 // Native libraries belonging to system classes.
2696 private static Map<String, NativeLibrary>
systemNativeLibraries = null;
2697
2698 // Native libraries associated with the class loader.
2699 private Map<String, NativeLibrary> nativeLibraries = null;
sure.
Mandy
