Code Review Request for 6977738

[Mandy Chung]

  Alan, David,

I revise the fix including the following:
1. Use the lazy initialization holder class idiom to initialize the bcp
variable to simplify the synchronization.

2. Group the initialization of system properties in a new private method
System.initializeSystemProperties so that it can save a copy for internal
implementation use to address the deadlock issue and remove the
properties that are intended for private internal use from public access
before initializing the System.props.  This removes the 2 calls to
System.setProperties.

3. Reorder sun.net.* in FILES_java.gmk

The new webrev is at:
    http://cr.openjdk.java.net/~mchung/6977738/webrev.01/

Thanks
Mandy

On 09/16/10 16:30, Mandy Chung wrote:
>
>
> Fix 6977738: Deadlock between java.lang.ClassLoader and 
> java.util.Properties
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/6977738/webrev.00/
>
> ClassLoader.getResource locking the system properties object is
> deadlock prone. For example, the 
> sun.misc.Launcher.getBootstrapClassPath()
> method is a synchronized method. A thread calling
> ClassLoader.getResource method attempts to synchronize on
> the system properties object while holding sun.misc.Launcher.class.
> It will deadlock if there is another thread is holding the monitor
> lock of the system properties object (e.g. calls the Properties.save()
> method) while it attempts to load a resource file.  In addition,
> ClassLoader.getResource may invoke the ZipFile initialization that
> also needs to get the system property.
>
> This fix caches the system properties at initialization so that
> the ZipFile and Launcher will read the system property from the
> private Properties object.  In addition, I make some minor
> changes in Properties.save and storeToXML method to confine the
> synchronization needed and also have the DownloadManager to
> maintain its bootclasspath.
>
> Thanks
> Mandy
>