JDK-8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Affected Version: 8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-12-10
  • Updated: 2021-09-14
  • Resolved: 2016-05-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u321Unresolved 9 b120Fixed
Related Reports
Blocks :  
JDK-8073100 - [javadoc] Provide an ability to suppress document generation for specific elements.
Relates :  
JDK-6977738 - Deadlock between java.lang.ClassLoader and java.util.Properties
Relates :  
JDK-8163272 - jhsdb jinfo cannot show system properties
Relates :  
JDK-8068427 - Hashtable deserialization reconstitutes table with wrong capacity
Relates :  
JDK-8157000 - Do not generate javadoc for overridden method with no spec change
Relates :  
JDK-8068347 - Add java/lang/ClassLoader/deadlock/GetResource.java to ProblemList.txt
Relates :  
JDK-8199435 - Unsafe publication of java.util.Properties.map
Relates :  
JDK-8186217 - Remove erroneous @hidden JavaDoc tag from java.util.Properties.replace(Object, Object, Object)
Sub Tasks
JDK-8175789 :  
Release Note: De-synchronize java.util.Properties getter methods - Closed
Description
 java/lang/ClassLoader/deadlock/GetResource.java fails by timeout

win32, jdk8 b119 and  macos, pit jdk8 b120 (fastdebug).

See jtrs attached.

deadlock?
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/01a8615439f0 User: lana Date: 2016-05-25 17:36:43 +0000
25-05-2016
URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0 User: bchristi Date: 2016-05-19 23:25:51 +0000
19-05-2016
All the method overrides needed to embed a CHM within Properties causes something of an explosion of additional JavaDoc. See http://cr.openjdk.java.net/~bchristi/8029891/webrev.3/specdiff-plain/Properties.html. It would be preferable to wait for something like a @nodoc tag, as suggested in JDK-8073100.
05-06-2015
I've written a test to detect if methods are added to Map or Hashtable, but not overridden in Properties. I plan to move forward with a fix, based on Peter's webrev. Thanks.
01-05-2015
@Mandy - The Serializable javadoc says: * Classes that require special handling during the serialization and * deserialization process must implement special methods with these exact * signatures: * * <PRE> * private void writeObject(java.io.ObjectOutputStream out) * throws IOException * private void readObject(java.io.ObjectInputStream in) * throws IOException, ClassNotFoundException; * private void readObjectNoData() * throws ObjectStreamException; * </PRE> ...so one can not inherit or override readObject/writeObject from a superclass. Since those two methods are meant to (de)serialize object state belonging to a particular class (without super or sub class state), this is understandable. To keep the Properties serialization format unchanged, it is important that the part of stream that gets (de)serialized as Hashtable class state is written/read as part of Hashtable.[writeObject,readObject] methods. In proposed patched Properties this state is moved to the embedded CHM, but must nevertheless be (de)serialized as part of Hashtable.[writeObject,readObject] methods. I think what I have proposed is the most simple way to achieve that.
04-01-2015
@Peter - your proposed solution is a good one by embedding ConcurrentHashMap and overriding all Hashtable methods to access the embedded CHM instead of this object. I like the idea of keeping Properties to serialize in the same format as a Hashtable to keep serialization/deserialization to work with different JDK release. I only skimmed on the webrev. I wonder if Properties should override readObject and writeObject methods and create a Hashtable in the implementation of serialization/deserialization reading from / writing to the CMH object instead of overriding the package-private writeHashtable and readHashtable. This would need a test to verify if Properties override all Map methods in case new method is added in a new JDK release. It'd be better to separate the Hashtable deserialization bug from this bug.
03-01-2015
Mandy writes: " ... 2) System.getProperties returns a copy of the current snapshot of the System Properties. The current spec of System.getProperties says that it determines the "current set" of system properties. Option 2 seems a reasonable solution but it has compatibility risk to existing code that uses a cached copy of System.getProperties and expects to read new properties added afterwards. This can only be fixed in a major release." Option 2 has another compatibility risk for code like this (even I have written code that takes a Properties object and merges in properties read from file - the Properties object is obtained from System.getProperties()): Properties props = System.getProperties(); ... props.setProperty(...); Another option is to make Properties methods not synchronized on the Properties instance itself. This might at first seem like an impossible thing to do since Properties is a subclass of Hashtable. Wouldn't it be nice if Properties was based on ConcurrentHashMap instead of Hashtable? CHM was designed to be a drop-in replacement for Hashtable, so this is actually very easy to achieve. We can't change the class hierarchy for Properties though, but we can override all Hashtable methods and delegate to embedded CHM instance instead of superclass. There's also some tricks to keep the serialization format unchanged, but otherwise very straightforward: http://cr.openjdk.java.net/~plevart/jdk9-dev/Properties.CHM/webrev.01/ Note that there is a bug in deserialization of Hashtable which reconstitutes the table with (size * loadFactor) buckets instead of (size / loadFactor) - tipycally the loadFactor is 0.75, so the reconstituted table has 0.75^2 as much buckets as original Hashtable and read performance suffers if no insertions are performed afterwards... I fixed that in this patch too. The jtreg tests seem to be happy with such Properties implementation. I remember reports of poor Properties.getProperty() multi-threaded scalability that would be solved with this too. What do you think?
31-12-2014
Sounds like this test needs to be added to ProblemList.txt: JDK-8068347.
29-12-2014
Since this is failing in nightlies for three weeks straight now we have to do something about it.
29-12-2014
This is a timeout with a fastdebug build, it clearly requires someone to look at the test to see if this is another deadlock or just the test running slow. In the core area then we use P3 for test stabilization issues, it is not a P1
16-12-2014
So far only a single sighting.
26-06-2014
David - do you observe that this test fails pretty often from our JPRT testing? This is an intermittent issue that exists in JDK 8. I haven't seen this test failing in my own testing (and also this is the only bug report so far I'm aware of) and thus didn't see the need to get this in ProblemList.txt. If you can reproduce it, I agree that it'd be good to get that in the ProblemList.txt.
24-06-2014
I'm getting a timeout with this test running 8u26 through JPRT. A lot of information above seems pertinent only to JDK 9, but the problem is filed against JDK 8. Is this a JDK 8 issue? If so why is it not in ProblemList.txt ? Thanks.
24-06-2014
Assign to Mandy to fixed since this is a product issue
23-01-2014
For java.uti.Properties, one alternative change is using ConcurrentHashMap to replace HashTable, but this will bring compatibility issue.
10-01-2014
Mandy - I apologize it looks like the 1st DeadLock was caught with wrong java version(1.6). We should skip it.
10-01-2014
Tristan - can you double check the first log with the deadlock detected is from JDK 8 test run? JDK 8 doesn't have sun.util.LocaleServiceProviderPool class - it's sun.util.locale.provider.LocaleServiceProviderPool instead. System Properties is a hashtable that synchronizes on itself for any access. Currently System.getProperties returns the Properties instance accessed by the system in which any application code might synchronize on it (that's what the test is doing). The problem reported JDK-6977738 is about Properties.store method that was fixed not to synchronize on this instance. System property is a common way for changing the default setting and so it's impractical to expect the class loading code path not to call System.getProperty. I see two options for resolving this problem at the moment - 1) will not fix - warn application code not to synchronize on the system Properties instance that may cause deadlock in the system and fix the test or 2) System.getProperties returns a copy of the current snapshot of the System Properties. The current spec of System.getProperties says that it determines the "current set" of system properties. Option 2 seems a reasonable solution but it has compatibility risk to existing code that uses a cached copy of System.getProperties and expects to read new properties added afterwards. This can only be fixed in a major release.
09-01-2014
This should be introduced in changeset http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7913855ff66c We add a new system property "java.util.secureRandomSeed". This property is going to be read when do loadClass.
09-01-2014
Second deadlock detected jstack 28343 2014-01-09 10:00:57 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed mode): "Attach Listener" #12 daemon prio=9 os_prio=31 tid=0x00007ffd2980c000 nid=0x4807 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Thread-1" #11 prio=5 os_prio=31 tid=0x00007ffd2c87c800 nid=0x6c03 waiting for monitor entry [0x00000001a4fce000] java.lang.Thread.State: BLOCKED (on object monitor) at java.util.Hashtable.get(Hashtable.java:362) - waiting to lock <0x0000000171c06568> (a java.util.Properties) at java.util.Properties.getProperty(Properties.java:974) at java.lang.System.getProperty(System.java:715) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:84) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:49) at java.security.AccessController.doPrivileged(Native Method) at java.util.concurrent.ThreadLocalRandom.initialSeed(ThreadLocalRandom.java:140) at java.util.concurrent.ThreadLocalRandom.<clinit>(ThreadLocalRandom.java:137) at java.util.concurrent.ConcurrentHashMap.fullAddCount(ConcurrentHashMap.java:2481) at java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2240) at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1052) at java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1517) at java.lang.ClassLoader.getClassLoadingLock(ClassLoader.java:463) at java.lang.ClassLoader.loadClass(ClassLoader.java:404) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at GetResource$2.run(GetResource.java:72) "Thread-0" #10 prio=5 os_prio=31 tid=0x00007ffd2c87c000 nid=0x6a03 waiting on condition [0x00000001a4ece000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000171da5768> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:234) at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:362) at GetResource$1.run(GetResource.java:53) - locked <0x0000000171c06568> (a java.util.Properties) "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007ffd28859800 nid=0x6603 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007ffd2884e800 nid=0x6403 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007ffd2884e000 nid=0x6203 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007ffd28842800 nid=0x6003 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007ffd28841000 nid=0x5e03 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007ffd2882e000 nid=0x5c03 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007ffd28825800 nid=0x4603 in Object.wait() [0x00000001a43ea000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000171c06218> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) - locked <0x0000000171c06218> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007ffd28825000 nid=0x4403 in Object.wait() [0x00000001a42e7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000171c05c88> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x0000000171c05c88> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=31 tid=0x00007ffd2a001000 nid=0x1d03 in Object.wait() [0x000000010d20c000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000171da63a0> (a GetResource$1) at java.lang.Thread.join(Thread.java:1244) - locked <0x0000000171da63a0> (a GetResource$1) at java.lang.Thread.join(Thread.java:1318) at GetResource.run(GetResource.java:93) at GetResource.main(GetResource.java:107) "VM Thread" os_prio=31 tid=0x00007ffd28822800 nid=0x4203 runnable "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007ffd2a011000 nid=0x3203 runnable "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007ffd2a012000 nid=0x3403 runnable "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007ffd2a012800 nid=0x3603 runnable "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007ffd2a013000 nid=0x3803 runnable "GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007ffd2a013800 nid=0x3a03 runnable "GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007ffd2a014800 nid=0x3c03 runnable "GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007ffd2a015000 nid=0x3e03 runnable "GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007ffd2a015800 nid=0x4003 runnable "VM Periodic Task Thread" os_prio=31 tid=0x00007ffd28829000 nid=0x6803 waiting on condition JNI global references: 7
09-01-2014
Root Cause: Deadlock happens when Thread t1 lock System properties, try to store a Date back to system properties, at the same time, Thread t2 start call sun.misc.Launcher.getBootstrapClassPath, which will call System.getProperty. Since system properties has been locked by t1, it's blocking, when t1 save back Date, it also need call sun.misc.Launcher.getBootstrapClassPath, since in t2 sun.misc.Launcher wasn't loaded succesfully. It's waiting also.
09-01-2014
Saw a deadlock in failed machine vmsqe-mac-20.ru.oracle.com jstack 41015 2014-01-06 06:28:00 Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.51-b01-457 mixed mode): "Attach Listener" daemon prio=9 tid=7ff01e95b000 nid=0x114201000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "Thread-3" daemon prio=5 tid=7ff021002800 nid=0x1136bf000 waiting for monitor entry [1136be000] java.lang.Thread.State: BLOCKED (on object monitor) at java.util.Hashtable.get(Hashtable.java:333) - waiting to lock <7f3001440> (a java.util.Properties) at java.util.Properties.getProperty(Properties.java:932) at java.lang.System.getProperty(System.java:670) at com.apple.java.AppleSystemLog.logToASL(AppleSystemLog.java:18) at com.apple.java.Usage.performReport(Usage.java:62) at com.apple.java.Usage.performAfterDelay(Usage.java:27) "Thread-2" prio=5 tid=7ff01b8c4000 nid=0x1140fe000 waiting for monitor entry [1140fc000] java.lang.Thread.State: BLOCKED (on object monitor) at java.util.Hashtable.get(Hashtable.java:333) - waiting to lock <7f3001440> (a java.util.Properties) at java.util.Properties.getProperty(Properties.java:932) at java.lang.System.getProperty(System.java:670) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:67) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:32) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.Launcher.getBootstrapClassPath(Launcher.java:362) - locked <7faff0728> (a java.lang.Class for sun.misc.Launcher) at java.lang.ClassLoader.getBootstrapClassPath(ClassLoader.java:1173) at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1149) at java.lang.ClassLoader.getResource(ClassLoader.java:999) at java.lang.ClassLoader.getResource(ClassLoader.java:997) at GetResource$2.run(GetResource.java:72) "Thread-1" prio=5 tid=7ff01b8c3000 nid=0x113ffb000 waiting for monitor entry [113ff9000] java.lang.Thread.State: BLOCKED (on object monitor) at sun.misc.Launcher.getBootstrapClassPath(Launcher.java:361) - waiting to lock <7faff0728> (a java.lang.Class for sun.misc.Launcher) at java.lang.ClassLoader.getBootstrapClassPath(ClassLoader.java:1173) at java.lang.ClassLoader.getBootstrapResources(ClassLoader.java:1160) at java.lang.ClassLoader.getResources(ClassLoader.java:1038) at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:323) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:422) at sun.util.LocaleServiceProviderPool$1.run(LocaleServiceProviderPool.java:100) at java.security.AccessController.doPrivileged(Native Method) at sun.util.LocaleServiceProviderPool.<init>(LocaleServiceProviderPool.java:98) at sun.util.LocaleServiceProviderPool.getPool(LocaleServiceProviderPool.java:80) at sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:86) at sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:81) at java.util.TimeZone.getDisplayNames(TimeZone.java:394) at java.util.TimeZone.getDisplayName(TimeZone.java:345) at java.util.Date.toString(Date.java:1025) at java.util.Properties.store0(Properties.java:807) at java.util.Properties.store(Properties.java:796) at GetResource$1.run(GetResource.java:52) - locked <7f3001440> (a java.util.Properties) "Low Memory Detector" daemon prio=5 tid=7ff01e95a800 nid=0x113c53000 runnable [00000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" daemon prio=9 tid=7ff01e959800 nid=0x113b50000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" daemon prio=9 tid=7ff01e959000 nid=0x113a4d000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=9 tid=7ff01e958000 nid=0x11394a000 runnable [00000000] java.lang.Thread.State: RUNNABLE "Surrogate Locker Thread (Concurrent GC)" daemon prio=5 tid=7ff01e957000 nid=0x113847000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=7ff01e93d800 nid=0x11363c000 in Object.wait() [11363b000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f3001300> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <7f3001300> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171) "Reference Handler" daemon prio=10 tid=7ff01e93c800 nid=0x113539000 in Object.wait() [113538000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f30011d8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <7f30011d8> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=7ff01f800800 nid=0x10b6c7000 in Object.wait() [10b6c6000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f3117d98> (a GetResource$1) at java.lang.Thread.join(Thread.java:1210) - locked <7f3117d98> (a GetResource$1) at java.lang.Thread.join(Thread.java:1263) at GetResource.run(GetResource.java:92) at GetResource.main(GetResource.java:106) "VM Thread" prio=9 tid=7ff01e938000 nid=0x113436000 runnable "Gang worker#0 (Parallel GC Threads)" prio=9 tid=7ff01e800800 nid=0x10eacc000 runnable "Gang worker#1 (Parallel GC Threads)" prio=9 tid=7ff01e801000 nid=0x10ebcf000 runnable "Gang worker#2 (Parallel GC Threads)" prio=9 tid=7ff01e802000 nid=0x10ecd2000 runnable "Gang worker#3 (Parallel GC Threads)" prio=9 tid=7ff01e802800 nid=0x10edd5000 runnable "Gang worker#4 (Parallel GC Threads)" prio=9 tid=7ff01e803000 nid=0x10eed8000 runnable "Gang worker#5 (Parallel GC Threads)" prio=9 tid=7ff01e803800 nid=0x10efdb000 runnable "Gang worker#6 (Parallel GC Threads)" prio=9 tid=7ff01e804800 nid=0x10f0de000 runnable "Gang worker#7 (Parallel GC Threads)" prio=9 tid=7ff01e805000 nid=0x10f1e1000 runnable "Concurrent Mark-Sweep GC Thread" prio=9 tid=7ff01e8e2800 nid=0x1130ad000 runnable "Gang worker#0 (Parallel CMS Threads)" prio=9 tid=7ff01e8e1000 nid=0x1126a7000 runnable "Gang worker#1 (Parallel CMS Threads)" prio=9 tid=7ff01e8e1800 nid=0x1127aa000 runnable "VM Periodic Task Thread" prio=10 tid=7ff01e96c000 nid=0x113d56000 waiting on condition "Exception Catcher Thread" prio=10 tid=7ff01f801800 nid=0x10b8f3000 runnable JNI global references: 900 Found one Java-level deadlock: ============================= "Thread-3": waiting to lock monitor 7ff01c007610 (object 7f3001440, a java.util.Properties), which is held by "Thread-1" "Thread-1": waiting to lock monitor 7ff01c00bc60 (object 7faff0728, a java.lang.Class), which is held by "Thread-2" "Thread-2": waiting to lock monitor 7ff01c007610 (object 7f3001440, a java.util.Properties), which is held by "Thread-1" Java stack information for the threads listed above: =================================================== "Thread-3": at java.util.Hashtable.get(Hashtable.java:333) - waiting to lock <7f3001440> (a java.util.Properties) at java.util.Properties.getProperty(Properties.java:932) at java.lang.System.getProperty(System.java:670) at com.apple.java.AppleSystemLog.logToASL(AppleSystemLog.java:18) at com.apple.java.Usage.performReport(Usage.java:62) at com.apple.java.Usage.performAfterDelay(Usage.java:27) "Thread-1": at sun.misc.Launcher.getBootstrapClassPath(Launcher.java:361) - waiting to lock <7faff0728> (a java.lang.Class for sun.misc.Launcher) at java.lang.ClassLoader.getBootstrapClassPath(ClassLoader.java:1173) at java.lang.ClassLoader.getBootstrapResources(ClassLoader.java:1160) at java.lang.ClassLoader.getResources(ClassLoader.java:1038) at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:323) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:422) at sun.util.LocaleServiceProviderPool$1.run(LocaleServiceProviderPool.java:100) at java.security.AccessController.doPrivileged(Native Method) at sun.util.LocaleServiceProviderPool.<init>(LocaleServiceProviderPool.java:98) at sun.util.LocaleServiceProviderPool.getPool(LocaleServiceProviderPool.java:80) at sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:86) at sun.util.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:81) at java.util.TimeZone.getDisplayNames(TimeZone.java:394) at java.util.TimeZone.getDisplayName(TimeZone.java:345) at java.util.Date.toString(Date.java:1025) at java.util.Properties.store0(Properties.java:807) at java.util.Properties.store(Properties.java:796) at GetResource$1.run(GetResource.java:52) - locked <7f3001440> (a java.util.Properties) "Thread-2": at java.util.Hashtable.get(Hashtable.java:333) - waiting to lock <7f3001440> (a java.util.Properties) at java.util.Properties.getProperty(Properties.java:932) at java.lang.System.getProperty(System.java:670) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:67) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:32) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.Launcher.getBootstrapClassPath(Launcher.java:362) - locked <7faff0728> (a java.lang.Class for sun.misc.Launcher) at java.lang.ClassLoader.getBootstrapClassPath(ClassLoader.java:1173) at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1149) at java.lang.ClassLoader.getResource(ClassLoader.java:999) at java.lang.ClassLoader.getResource(ClassLoader.java:997) at GetResource$2.run(GetResource.java:72) Found 1 deadlock.
06-01-2014
It takes a second to finish. I tried to reproduce the failure running in a loop on win and solaris x64, but test passed... Looks like race condition.
14-12-2013
Dimitry - if you run this interactively (not in jtreg) then how long does the test take? I just want to be sure that the test does actually terminate, just in case there is something in hotspot or elsewhere that might be causing this.
10-12-2013