June 2014 - core-libs-dev

Re: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo
by Alan Bateman 24 Jun '14

24 Jun '14

On 20/06/2014 09:42, Patrick Zhang wrote: > Hi Team, > > 8035490 is one task used to track xml code colocation from sqe repo > into jaxp repo. > As one initial change set, it includes below materials: > 1. TEST.ROOT to declare test code location. > 2. ProblemList.txt to exclude 6 tests which have been discussed on past. > 3. One Makefile to support future jprt/aurora execution. > 4. test code located in bugxxx dir. All are based on testNG. > > > webrev: > http://cr.openjdk.java.net/~pzhang/xml_colocation/8035490/webrev/ > > : > (Moving this thread this to core-libs-dev). At a high-level then it's good to have the tests for JAXP in the same repository as the code. I've only skimmed over these webrev (not a review) and they look like they are mostly regression tests for specific bugs - is that right? One thing that concerns me a bit is that none of the .java files that I looked at have any comments to say what the test does. Is there anything that could be brought over from the original issue in JIRA to explain what each of these tests is about? Is Hello.wsdl.data a binary file? Have any alternatives been looked at? As you mention ProblemList.txt then I see that it has headings that don't make sense in the jaxp repository, maybe they should be removed. The webrev only has the changes for jaxp repository, will there be follow-on changes to make it runnable at the top level, JPRT configuration, etc. -Alan

2 3

Review request for 8047904: Runtime.loadLibrary throws SecurityException when security manager is installed
by Mandy Chung 24 Jun '14

24 Jun '14

The loadLibrary implementation is missing to wrap the call to File.getCanonicalPath method with doPrivileged block. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/ thanks Mandy

3 2

Re: [concurrency-interest] Deadlock
by Martin Buchholz 24 Jun '14

24 Jun '14

[+openjdk mailing lists] Yeah, I'm trying to excise all the networking code from TLR and SplittableRandom. There is also likely to be a missing wrapping in doPrivileged. On Tue, Jun 24, 2014 at 7:21 AM, Peter Levart <peter.levart(a)gmail.com> wrote: > On 06/24/2014 04:12 PM, Peter Levart wrote: > >> On 06/24/2014 01:09 PM, David Holmes wrote: >> >>> Hi Peter, >>> >>> What a strange coincidence - the fact that the initialization of >>> ThreadLocalRandom can lead to arbitrary code execution has just been a >>> topic >>> of discussion, and it looks like your deadlock is related to that. >>> >> >> Uf, this time it's a combination of a custom SecurityManager being in >> effect when NetworkInterface.getHardwareAddress() is called. It looks >> like we should not use any networking code at all for TLR's initialization. >> > > Or make NetworkInterface.getHardwareAddress() a @CallerSensitive method > and avoid SecurityManager invocation when called from one of system > classes. That's still an alternative. > > Peter > > > >> Regards, Peter >> >> >>> David Holmes >>> >>> -----Original Message----- >>>> From: concurrency-interest-bounces(a)cs.oswego.edu >>>> [mailto:concurrency-interest-bounces@cs.oswego.edu]On Behalf Of Peter >>>> Firmstone >>>> Sent: Tuesday, 24 June 2014 8:25 PM >>>> To: concurrency-interest(a)cs.oswego.edu >>>> Subject: [concurrency-interest] Deadlock >>>> >>>> >>>> This appears to be a ClassLoader deadlock in Java 7. >>>> >>>> The stack trace from the main thread is missing. >>>> >>>> Any ideas? >>>> >>>> Regards, >>>> >>>> Peter. >>>> >>>> Attaching to process ID 7124, please wait... >>>> Debugger attached successfully. >>>> Client compiler detected. >>>> JVM version is 25.0-b70 >>>> Deadlock Detection: >>>> >>>> Found one Java-level deadlock: >>>> ============================= >>>> >>>> "main": >>>> waiting to lock Monitor@0x0094bb2c (Object@0x03d73c38, a >>>> java/lang/Object), >>>> which is held by "Thread-1" >>>> "Thread-1": >>>> waiting to lock Monitor@0x0094c99c (Object@0x03f02e50, a [I), >>>> which is held by "main" >>>> >>>> Found a total of 1 deadlock. >>>> >>>> Thread 8: (state = BLOCKED) >>>> - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229, >>>> line=60 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=37, line=128 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=4, line=44 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, >>>> boolean, boolean) @bci=7, line=248 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) @bci=8, line=67 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) @bci=161, line=260 (Interpreted frame) >>>> - >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTr >>>> ustPermission(java.lang.Class) >>>> @bci=59, line=1848 (Interpreted frame) >>>> - >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBea >>>> n(java.lang.Object, >>>> javax.management.ObjectName) @bci=25, line=322 (Interpreted frame) >>>> - com.sun.jmx.mbeanserver.JmxMBeanServer$2.run() @bci=17, line=1225 >>>> (Interpreted frame) >>>> - >>>> java.security.AccessController.doPrivileged(java.security.Privileg >>>> edExceptionAction) >>>> @bci=0 (Interpreted frame) >>>> - com.sun.jmx.mbeanserver.JmxMBeanServer.initialize() @bci=25, >>>> line=1223 (Interpreted frame) >>>> - com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> com.sun.jmx.mbeanserver.MBeanInstantiator, boolean, boolean) @bci=133, >>>> line=255 (Interpreted frame) >>>> - >>>> com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> boolean) @bci=13, line=1437 (Interpreted frame) >>>> - javax.management.MBeanServerBuilder.newMBeanServer(java.lang. >>>> String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate) >>>> @bci=4, line=110 (Interpreted frame) >>>> - javax.management.MBeanServerFactory.newMBeanServer(java.lang. >>>> String) >>>> @bci=36, line=329 (Interpreted frame) >>>> - >>>> javax.management.MBeanServerFactory.createMBeanServer(java.lang.String) >>>> @bci=6, line=231 (Interpreted frame) >>>> - javax.management.MBeanServerFactory.createMBeanServer() @bci=1, >>>> line=192 (Interpreted frame) >>>> - java.lang.management.ManagementFactory.getPlatformMBeanServer() >>>> @bci=29, line=468 (Interpreted frame) >>>> - >>>> sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer() >>>> @bci=66, line=518 (Interpreted frame) >>>> - sun.management.Agent.startLocalManagementAgent() @bci=13, line=138 >>>> (Interpreted frame) >>>> - sun.management.Agent.startAgent(java.util.Properties) @bci=76, >>>> line=260 (Interpreted frame) >>>> - sun.management.Agent.agentmain(java.lang.String) @bci=45, line=128 >>>> (Interpreted frame) >>>> - >>>> sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>>> - java.lang.reflect.Method.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=56, line=483 (Interpreted frame) >>>> - >>>> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.lan >>>> g.String, >>>> java.lang.String, java.lang.String) @bci=192, line=388 (Interpreted >>>> frame) >>>> - >>>> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java. >>>> lang.String, >>>> java.lang.String) @bci=5, line=411 (Interpreted frame) >>>> >>>> >>>> Thread 7: (state = BLOCKED) >>>> >>>> >>>> Thread 5: (state = BLOCKED) >>>> - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229, >>>> line=60 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=37, line=128 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=4, line=44 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, >>>> boolean, boolean) @bci=7, line=248 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) @bci=8, line=67 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) @bci=161, line=260 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission) >>>> @bci=27, line=202 (Interpreted frame) >>>> - java.net.NetworkInterface.getHardwareAddress() @bci=18, line=447 >>>> (Interpreted frame) >>>> - java.util.concurrent.ThreadLocalRandom.initialSeed() @bci=116, >>>> line=158 (Interpreted frame) >>>> - java.util.concurrent.ThreadLocalRandom.<clinit>() @bci=14, >>>> line=137 >>>> (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.fullAddCount(long, boolean) >>>> @bci=0, line=2526 (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.addCount(long, int) >>>> @bci=104, >>>> line=2266 (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.putVal(java.lang.Object, >>>> java.lang.Object, boolean) @bci=357, line=1070 (Interpreted frame) >>>> - java.util.concurrent.ConcurrentHashMap.putIfAbsent( >>>> java.lang.Object, >>>> java.lang.Object) @bci=4, line=1535 (Interpreted frame) >>>> - java.lang.ClassLoader.getClassLoadingLock(java.lang.String) >>>> @bci=23, >>>> line=463 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String, boolean) @bci=2, >>>> line=404 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String, boolean) >>>> @bci=38, >>>> line=411 (Interpreted frame) >>>> - sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, >>>> boolean) @bci=36, line=308 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String) @bci=3, line=357 >>>> (Interpreted frame) >>>> - >>>> org.cliffc.high_scale_lib.NonBlockingHashMap$SnapshotK.<init>(org. >>>> >>> cliffc.high_scale_lib.NonBlockingHashMap) >>> >>>> @bci=10, line=1167 (Interpreted frame) >>>> - org.cliffc.high_scale_lib.NonBlockingHashMap$2.iterator() @bci=8, >>>> line=1200 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run() >>>> @bci=15, line=166 (Interpreted frame) >>>> - java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, >>>> line=511 (Interpreted frame) >>>> - java.util.concurrent.FutureTask.runAndReset() @bci=47, line=308 >>>> (Interpreted frame) >>>> - >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$Sch >>>> eduledFutureTask) >>>> @bci=1, line=180 (Interpreted frame) >>>> - >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.run() >>>> @bci=37, line=294 (Interpreted frame) >>>> - >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concur >>>> rent.ThreadPoolExecutor$Worker) >>>> @bci=95, line=1142 (Interpreted frame) >>>> - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, >>>> line=617 (Interpreted frame) >>>> - java.lang.Thread.run() @bci=11, line=744 (Interpreted frame) >>>> >>>> >>>> Thread 4: (state = BLOCKED) >>>> - java.lang.Object.wait(long) @bci=0 (Interpreted frame) >>>> - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=142 >>>> (Interpreted frame) >>>> - java.lang.ref.ReferenceQueue.remove() @bci=2, line=158 >>>> (Interpreted >>>> frame) >>>> - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 >>>> (Interpreted frame) >>>> >>>> >>>> Thread 3: (state = BLOCKED) >>>> - java.lang.Object.wait(long) @bci=0 (Interpreted frame) >>>> - java.lang.Object.wait() @bci=2, line=502 (Interpreted frame) >>>> - java.lang.ref.Reference$ReferenceHandler.run() @bci=36, line=157 >>>> (Interpreted frame) >>>> >>>> >>>> Thread 1: (state = BLOCKED) >>>> - java.lang.ClassLoader.loadClass(java.lang.String, boolean) @bci=8, >>>> line=406 (Interpreted frame) >>>> - sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, >>>> boolean) @bci=36, line=308 (Interpreted frame) >>>> - java.lang.ClassLoader.loadClass(java.lang.String) @bci=3, line=357 >>>> (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) @bci=229, >>>> line=60 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=37, line=128 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) @bci=4, line=44 (Interpreted frame) >>>> - au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, >>>> boolean, boolean) @bci=7, line=248 (Interpreted frame) >>>> - >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) @bci=8, line=67 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) @bci=161, line=260 (Interpreted frame) >>>> - >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission) >>>> @bci=27, line=202 (Interpreted frame) >>>> - java.lang.System.checkIO() @bci=18, line=253 (Interpreted frame) >>>> - java.lang.System.setErr(java.io.PrintStream) @bci=0, line=199 >>>> (Interpreted frame) >>>> - com.sun.jini.qa.harness.MasterTest.main(java.lang.String[]) >>>> @bci=9, >>>> line=84 (Interpreted frame) >>>> >>>> The long version: >>>> >>>> Attaching to process ID 7124, please wait... >>>> Debugger attached successfully. >>>> Client compiler detected. >>>> JVM version is 25.0-b70 >>>> Deadlock Detection: >>>> >>>> Found one Java-level deadlock: >>>> ============================= >>>> >>>> "main": >>>> waiting to lock Monitor@0x0094bb2c (Object@0x03d73c38, a >>>> java/lang/Object), >>>> which is held by "Thread-1" >>>> "Thread-1": >>>> waiting to lock Monitor@0x0094c99c (Object@0x03f02e50, a [I), >>>> which is held by "main" >>>> >>>> Found a total of 1 deadlock. >>>> >>>> ----------------- 0 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x00e64d7b java + 0x4d7b >>>> 0x00e631ca java + 0x31ca >>>> 0x00e642ab java + 0x42ab >>>> 0x00e63440 java + 0x3440 >>>> 0x00130138 ???????? >>>> ----------------- 1 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal@4 + 0x286d >>>> 0x5bf7857e jvm!JVM_GetThreadStateNames + 0x4c12e >>>> 0x5bf78b23 jvm!JVM_GetThreadStateNames + 0x4c6d3 >>>> 0x5bf8e107 jvm!JVM_GetThreadStateNames + 0x61cb7 >>>> 0x5bf8e6be jvm!JVM_GetThreadStateNames + 0x6226e >>>> 0x5bea1b28 jvm + 0x71b28 >>>> 0x01aa1cef * java.lang.ClassLoader.loadClass(java.lang.String, >>>> boolean) bci:8 line:406 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean) >>>> bci:36 line:308 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String) bci:3 >>>> line:357 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf7258f jvm!JVM_GetThreadStateNames + 0x4613f >>>> 0x5be77d6f jvm + 0x47d6f >>>> 0x5be7822a jvm + 0x4822a >>>> 0x5be794c0 jvm + 0x494c0 >>>> 0x5be7950a jvm + 0x4950a >>>> 0x5bf20de5 jvm!_JVM_FindClassFromClass@16 + 0x135 >>>> 0x73b515cd verify + 0x15cd >>>> 0x73b51d53 verify + 0x1d53 >>>> 0x73b52c67 verify + 0x2c67 >>>> 0x14d6f5e8 ???????? >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 2 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal@4 + 0x286d >>>> 0x5bf73ecc jvm!JVM_GetThreadStateNames + 0x47a7c >>>> 0x5bf741fc jvm!JVM_GetThreadStateNames + 0x47dac >>>> 0x5bf99671 jvm!JVM_GetThreadStateNames + 0x6d221 >>>> 0x5bf99a32 jvm!JVM_GetThreadStateNames + 0x6d5e2 >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> ----------------- 3 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal@4 + 0x2979 >>>> 0x5bf78f56 jvm!JVM_GetThreadStateNames + 0x4cb06 >>>> 0x5bf8e334 jvm!JVM_GetThreadStateNames + 0x61ee4 >>>> 0x5bf20c15 jvm!_JVM_MonitorWait@16 + 0x95 >>>> 0x01a9ac63 * java.lang.Object.wait(long) bci:0 (Interpreted frame) >>>> 0x01a940f4 * java.lang.Object.wait() bci:2 line:502 (Interpreted >>>> frame) >>>> 0x01a940f4 * java.lang.ref.Reference$ReferenceHandler.run() bci:36 >>>> line:157 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf72517 jvm!JVM_GetThreadStateNames + 0x460c7 >>>> 0x5bf1de0f jvm!jio_printf + 0x9f >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 4 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal@4 + 0x2979 >>>> 0x5bf78f56 jvm!JVM_GetThreadStateNames + 0x4cb06 >>>> 0x5bf8e334 jvm!JVM_GetThreadStateNames + 0x61ee4 >>>> 0x5bf20c15 jvm!_JVM_MonitorWait@16 + 0x95 >>>> 0x01a9ac63 * java.lang.Object.wait(long) bci:0 (Interpreted frame) >>>> 0x01a940f4 * java.lang.ref.ReferenceQueue.remove(long) bci:44 >>>> line:142 (Interpreted frame) >>>> 0x01a94054 * java.lang.ref.ReferenceQueue.remove() bci:2 line:158 >>>> (Interpreted frame) >>>> 0x01a94054 * java.lang.ref.Finalizer$FinalizerThread.run() bci:36 >>>> line:209 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf72517 jvm!JVM_GetThreadStateNames + 0x460c7 >>>> 0x5bf1de0f jvm!jio_printf + 0x9f >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 5 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal@4 + 0x286d >>>> 0x5bf7857e jvm!JVM_GetThreadStateNames + 0x4c12e >>>> 0x5bf78b23 jvm!JVM_GetThreadStateNames + 0x4c6d3 >>>> 0x5bf8e107 jvm!JVM_GetThreadStateNames + 0x61cb7 >>>> 0x5bf8e6be jvm!JVM_GetThreadStateNames + 0x6226e >>>> 0x5bf8e78f jvm!JVM_GetThreadStateNames + 0x6233f >>>> 0x5bee0d10 jvm + 0xb0d10 >>>> 0x5bee2854 jvm + 0xb2854 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea5641 jvm + 0x75641 >>>> 0x01aa17be * >>>> au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) bci:229 >>>> line:60 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:37 line:128 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:4 line:44 (Interpreted frame) >>>> 0x01a94089 * >>>> au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, boolean, >>>> boolean) bci:7 line:248 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) bci:8 line:67 (Interpreted frame) >>>> 0x01a94089 * >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) bci:161 line:260 (Interpreted frame) >>>> 0x01a940f4 * >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission) >>>> bci:27 line:202 (Interpreted frame) >>>> 0x01a940f4 * java.net.NetworkInterface.getHardwareAddress() bci:18 >>>> line:447 (Interpreted frame) >>>> 0x01a94054 * java.util.concurrent.ThreadLocalRandom.initialSeed() >>>> bci:116 line:158 (Interpreted frame) >>>> 0x01a93e20 * java.util.concurrent.ThreadLocalRandom.<clinit>() >>>> bci:14 >>>> line:137 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bee0f44 jvm + 0xb0f44 >>>> 0x5bee2b21 jvm + 0xb2b21 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea9796 jvm + 0x79796 >>>> 0x5beaa7b2 jvm + 0x7a7b2 >>>> 0x5bea5dc7 jvm + 0x75dc7 >>>> 0x01aa12ae * >>>> java.util.concurrent.ConcurrentHashMap.fullAddCount(long, boolean) >>>> bci:0 >>>> line:2526 (Interpreted frame) >>>> 0x01a940f4 * java.util.concurrent.ConcurrentHashMap.addCount(long, >>>> int) bci:104 line:2266 (Interpreted frame) >>>> 0x01a940f4 * >>>> java.util.concurrent.ConcurrentHashMap.putVal(java.lang.Object, >>>> java.lang.Object, boolean) bci:357 line:1070 (Interpreted frame) >>>> 0x01a94054 * >>>> java.util.concurrent.ConcurrentHashMap.putIfAbsent(java.lang.Object, >>>> java.lang.Object) bci:4 line:1535 (Interpreted frame) >>>> 0x01a94054 * >>>> java.lang.ClassLoader.getClassLoadingLock(java.lang.String) bci:23 >>>> line:463 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String, >>>> boolean) bci:2 line:404 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String, >>>> boolean) bci:38 line:411 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean) >>>> bci:36 line:308 (Interpreted frame) >>>> 0x01a94054 * java.lang.ClassLoader.loadClass(java.lang.String) bci:3 >>>> line:357 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf7258f jvm!JVM_GetThreadStateNames + 0x4613f >>>> 0x5be77d6f jvm + 0x47d6f >>>> 0x5be7822a jvm + 0x4822a >>>> 0x5be794c0 jvm + 0x494c0 >>>> 0x5be7950a jvm + 0x4950a >>>> 0x5be79f66 jvm + 0x49f66 >>>> 0x5be715c7 jvm + 0x415c7 >>>> 0x5be7a53c jvm + 0x4a53c >>>> 0x5be817e2 jvm + 0x517e2 >>>> 0x5be822d9 jvm + 0x522d9 >>>> 0x5be82414 jvm + 0x52414 >>>> 0x5bed85dd jvm + 0xa85dd >>>> 0x5bee0d80 jvm + 0xb0d80 >>>> 0x5bee2854 jvm + 0xb2854 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea5641 jvm + 0x75641 >>>> 0x01aa17be * >>>> org.cliffc.high_scale_lib.NonBlockingHashMap$SnapshotK.<init>(org. >>>> >>> cliffc.high_scale_lib.NonBlockingHashMap) >>> >>>> bci:10 line:1167 (Interpreted frame) >>>> 0x01a940f4 * >>>> org.cliffc.high_scale_lib.NonBlockingHashMap$2.iterator() bci:8 >>>> line:1200 (Interpreted frame) >>>> 0x01a94089 * >>>> au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run() bci:15 >>>> line:166 (Interpreted frame) >>>> 0x01a94129 * java.util.concurrent.Executors$RunnableAdapter.call() >>>> bci:4 line:511 (Interpreted frame) >>>> 0x01a94089 * java.util.concurrent.FutureTask.runAndReset() bci:47 >>>> line:308 (Interpreted frame) >>>> 0x01a93ba0 * >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$Sch >>>> eduledFutureTask) >>>> bci:1 line:180 (Interpreted frame) >>>> 0x01a93ba0 * >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa >>>> sk.run() >>>> bci:37 line:294 (Interpreted frame) >>>> 0x01a94129 * >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concur >>>> rent.ThreadPoolExecutor$Worker) >>>> bci:95 line:1142 (Interpreted frame) >>>> 0x01a940f4 * java.util.concurrent.ThreadPoolExecutor$Worker.run() >>>> bci:5 line:617 (Interpreted frame) >>>> 0x01a94129 * java.lang.Thread.run() bci:11 line:744 (Interpreted >>>> frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf724a6 jvm!JVM_GetThreadStateNames + 0x46056 >>>> 0x5bf72517 jvm!JVM_GetThreadStateNames + 0x460c7 >>>> 0x5bf1de0f jvm!jio_printf + 0x9f >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - <0x03d58650>, (a java/util/concurrent/ >>>> ThreadPoolExecutor$Worker) >>>> ----------------- 6 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> ----------------- 7 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd9539 jvm!_JVM_FindSignal@4 + 0x5269 >>>> 0x5bfd9607 jvm!_JVM_FindSignal@4 + 0x5337 >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 8 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal@4 + 0x2979 >>>> 0x5bf7856b jvm!JVM_GetThreadStateNames + 0x4c11b >>>> 0x5bf78b23 jvm!JVM_GetThreadStateNames + 0x4c6d3 >>>> 0x5bf8e107 jvm!JVM_GetThreadStateNames + 0x61cb7 >>>> 0x5bf8e6be jvm!JVM_GetThreadStateNames + 0x6226e >>>> 0x5bf8e78f jvm!JVM_GetThreadStateNames + 0x6233f >>>> 0x5bee0d10 jvm + 0xb0d10 >>>> 0x5bee2854 jvm + 0xb2854 >>>> 0x5bee3548 jvm + 0xb3548 >>>> 0x5bea5641 jvm + 0x75641 >>>> 0x01aa17be * >>>> au.net.zeus.collection.ReferenceFactory.create(java.lang.Object, >>>> au.net.zeus.collection.RefQueue, au.net.zeus.collection.Ref) bci:229 >>>> line:60 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:37 line:128 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceProcessor.referenced(java.lang.Object, >>>> boolean, boolean) bci:4 line:44 (Interpreted frame) >>>> 0x01a94089 * >>>> au.net.zeus.collection.ReferenceMap.wrapKey(java.lang.Object, boolean, >>>> boolean) bci:7 line:248 (Interpreted frame) >>>> 0x01a94054 * >>>> au.net.zeus.collection.ReferenceConcurrentMap.putIfAbsent(java.lan >>>> g.Object, >>>> java.lang.Object) bci:8 line:67 (Interpreted frame) >>>> 0x01a94089 * >>>> org.apache.river.api.security.CombinerSecurityManager.checkPermiss >>>> ion(java.security.Permission, >>>> java.lang.Object) bci:161 line:260 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTr >>>> ustPermission(java.lang.Class) >>>> bci:59 line:1848 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBea >>>> n(java.lang.Object, >>>> javax.management.ObjectName) bci:25 line:322 (Interpreted frame) >>>> 0x01a94089 * com.sun.jmx.mbeanserver.JmxMBeanServer$2.run() bci:17 >>>> line:1225 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf299ed jvm!_JVM_DoPrivileged@20 + 0x2bd >>>> 0x73b21047 >>>> java_73b20000!_Java_java_security_AccessController_doPrivileged__L >>>> java_security_PrivilegedExceptionAction_2@12 >>>> + 0x15 >>>> 0x01a94054 * com.sun.jmx.mbeanserver.JmxMBeanServer.initialize() >>>> bci:25 line:1223 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> com.sun.jmx.mbeanserver.MBeanInstantiator, boolean, boolean) bci:133 >>>> line:255 (Interpreted frame) >>>> 0x01a940f4 * >>>> com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate, >>>> boolean) bci:13 line:1437 (Interpreted frame) >>>> 0x01a94054 * >>>> javax.management.MBeanServerBuilder.newMBeanServer(java.lang.String, >>>> javax.management.MBeanServer, javax.management.MBeanServerDelegate) >>>> bci:4 line:110 (Interpreted frame) >>>> 0x01a94054 * >>>> javax.management.MBeanServerFactory.newMBeanServer(java.lang.String) >>>> bci:36 line:329 (Interpreted frame) >>>> 0x01a94054 * >>>> javax.management.MBeanServerFactory.createMBeanServer(java.lang.String) >>>> bci:6 line:231 (Interpreted frame) >>>> 0x01a94054 * javax.management.MBeanServerFactory.createMBeanServer() >>>> bci:1 line:192 (Interpreted frame) >>>> 0x01a94054 * >>>> java.lang.management.ManagementFactory.getPlatformMBeanServer() bci:29 >>>> line:468 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer() >>>> bci:66 line:518 (Interpreted frame) >>>> 0x01a94054 * sun.management.Agent.startLocalManagementAgent() bci:13 >>>> line:138 (Interpreted frame) >>>> 0x01a940f4 * sun.management.Agent.startAgent(java.util.Properties) >>>> bci:76 line:260 (Interpreted frame) >>>> 0x01a940f4 * sun.management.Agent.agentmain(java.lang.String) bci:45 >>>> line:128 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5bf7e73a jvm!JVM_GetThreadStateNames + 0x522ea >>>> 0x5bf7e993 jvm!JVM_GetThreadStateNames + 0x52543 >>>> 0x5bf22b03 jvm!_JVM_InvokeMethod@16 + 0xb3 >>>> 0x73b23a6e >>>> java_73b20000!_Java_sun_reflect_NativeMethodAccessorImpl_invoke0@20 + >>>> 0x15 >>>> 0x01a94054 * >>>> sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) bci:100 line:62 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) bci:6 line:43 (Interpreted frame) >>>> 0x01a94089 * java.lang.reflect.Method.invoke(java.lang.Object, >>>> java.lang.Object[]) bci:56 line:483 (Interpreted frame) >>>> 0x01a94054 * >>>> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.lan >>>> g.String, >>>> java.lang.String, java.lang.String) bci:192 line:388 (Interpreted frame) >>>> 0x01a940f4 * >>>> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java. >>>> lang.String, >>>> java.lang.String) bci:5 line:411 (Interpreted frame) >>>> 0x01a903d7 <StubRoutines> >>>> 0x5bf72285 jvm!JVM_GetThreadStateNames + 0x45e35 >>>> 0x5c0370be jvm!_JVM_FindSignal@4 + 0x62dee >>>> 0x5bf7231e jvm!JVM_GetThreadStateNames + 0x45ece >>>> 0x5befe951 jvm!JNI_GetCreatedJavaVMs + 0x71a1 >>>> 0x5bf01788 jvm!JNI_GetCreatedJavaVMs + 0x9fd8 >>>> 0x6db62878 instrument!Agent_OnAttach + 0x76b >>>> 0x6db63eea instrument!Agent_OnAttach + 0x1ddd >>>> 0x6db6234a instrument!Agent_OnAttach + 0x23d >>>> 0x5bf3c50c jvm!JVM_GetThreadStateNames + 0x100bc >>>> 0x5bf9b05e jvm!JVM_GetThreadStateNames + 0x6ec0e >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 9 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal@4 + 0x286d >>>> 0x5bf73ecc jvm!JVM_GetThreadStateNames + 0x47a7c >>>> 0x5bf7424a jvm!JVM_GetThreadStateNames + 0x47dfa >>>> 0x5be9253b jvm + 0x6253b >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 10 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6c49 jvm!_JVM_FindSignal@4 + 0x2979 >>>> 0x5bf73ec1 jvm!JVM_GetThreadStateNames + 0x47a71 >>>> 0x5bf741fc jvm!JVM_GetThreadStateNames + 0x47dac >>>> 0x5bf829a5 jvm!JVM_GetThreadStateNames + 0x56555 >>>> 0x5bf945fc jvm!JVM_GetThreadStateNames + 0x681ac >>>> 0x5bf94e8a jvm!JVM_GetThreadStateNames + 0x68a3a >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> Locked ownable synchronizers: >>>> - None >>>> ----------------- 11 ----------------- >>>> 0x77c870f4 ntdll!KiFastSystemCallRet >>>> 0x76a9c3d3 kernel32!WaitForSingleObjectEx + 0x43 >>>> 0x76a9c382 kernel32!WaitForSingleObject + 0x12 >>>> 0x5bfd6b3d jvm!_JVM_FindSignal@4 + 0x286d >>>> 0x5bf73ecc jvm!JVM_GetThreadStateNames + 0x47a7c >>>> 0x5bf741fc jvm!JVM_GetThreadStateNames + 0x47dac >>>> 0x5bf8f904 jvm!JVM_GetThreadStateNames + 0x634b4 >>>> 0x5bf8f9a7 jvm!JVM_GetThreadStateNames + 0x63557 >>>> 0x5bfd9186 jvm!_JVM_FindSignal@4 + 0x4eb6 >>>> 0x614dc556 msvcr100!_endthreadex + 0x3a >>>> 0x614dc600 msvcr100!_endthreadex + 0xe4 >>>> 0x76a9ee1c kernel32!BaseThreadInitThunk + 0x12 >>>> 0x77ca37eb ntdll!RtlInitializeExceptionChain + 0xef >>>> 0x77ca37be ntdll!RtlInitializeExceptionChain + 0xc2 >>>> >>>> >>>> _______________________________________________ >>>> Concurrency-interest mailing list >>>> Concurrency-interest(a)cs.oswego.edu >>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >>>> >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest(a)cs.oswego.edu >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >>> >> >> > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest(a)cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest >

1 0

Re: RFR 6642881: Improve performance of Class.getClassLoader()
by Coleen Phillimore 24 Jun '14

24 Jun '14

Please review a change to the JDK code for adding classLoader field to the instances of java/lang/Class. This change restricts reflection from changing access to the classLoader field. In the spec, AccessibleObject.setAccessible() may throw SecurityException if the accessibility of an object may not be changed: http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject… Only AccessibleObject.java has changes from the previous version of this change. open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/ bug link https://bugs.openjdk.java.net/browse/JDK-6642881 Thanks, Coleen On 6/19/14, 11:01 PM, David Holmes wrote: > On 20/06/2014 6:53 AM, Joel Borggrén-Franck wrote: >> Hi Mandy, >> >> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung(a)oracle.com> wrote: >> >>> On 6/19/14 12:34 PM, Joel Borggrén-Franck wrote: >>>> Hi, >>>> >>>> On 19 jun 2014, at 20:46, Coleen Phillimore >>>> <coleen.phillimore(a)oracle.com> wrote: >>>>> On 6/17/14, 12:38 AM, Joel Borggrén-Franck wrote: >>>>>> Have you considered hiding the Class.classLoader field from >>>>>> reflection? I’m not sure it is necessary but I’m not to keen on >>>>>> the idea of people poking at this field with Unsafe (which should >>>>>> go away in 9 but …). >>>>> I don't know how to hide the field from reflection. It's a >>>>> private final field so you need to get priviledges to make it >>>>> setAccessible. If you mean injecting it on the JVM side, the >>>>> reason for this change is so that the JIT compilers can inline >>>>> this call and not have to call into the JVM to get the class loader. >>>>> >>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides >>>> a field from being found using reflection. It might very well be >>>> the case that private and final is enough, I haven’t thought this >>>> through 100%. On the other hand, is there a reason to give users >>>> access through the field instead of having to use >>>> Class.getClassLoader()? >>>> >>> There are many getter methods that returns a private final field. >>> I'm not sure if hiding the field is necessary nor a good precedence >>> to set. Accessing a private field requires "accessDeclaredMember" >>> permission although it's a different security check (vs >>> "getClassLoader" >>> permission). Arguably before this new classLoader field, one could >>> call Class.getClassLoader0() via reflection to get a hold of class >>> loader. >>> >>> Perhaps you are concerned that the "accessDeclaredMember" permission >>> is too coarse-grained? I think the security team is looking into >>> the improvement in that regards. >> >> I think I’m a bit worried about two things, first as you wrote, >> “accessDeclaredMember” isn’t the same as “getClassLoader”, but since >> you could get the class loader through getClassLoader0() that >> shouldn’t be a new issue. >> >> The second thing is that IIRC there are ways to set a final field >> after initialization. I’m not sure we need to care about that either >> if you need Unsafe to do it. > > Normal reflection can set a final field if you can successfully call > setAccessible(true) on the Field object. > > David > ----- > > >> cheers >> /Joel >>

6 10

Re: RFR 6642881: Improve performance of Class.getClassLoader()
by Coleen Phillimore 24 Jun '14

24 Jun '14

Mikael, see below. On 6/24/14, 9:48 AM, Mikael Gerdin wrote: > On Tuesday 24 June 2014 08.51.18 Coleen Phillimore wrote: >> Hi Peter, >> >> On 6/24/14, 4:23 AM, Peter Levart wrote: >>> On 06/24/2014 01:45 AM, Coleen Phillimore wrote: >>>> Please review a change to the JDK code for adding classLoader field >>>> to the instances of java/lang/Class. This change restricts >>>> reflection from changing access to the classLoader field. In the >>>> spec, AccessibleObject.setAccessible() may throw SecurityException if >>>> the accessibility of an object may not be changed: >>>> >>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObje >>>> ct.html#setAccessible(boolean) >>>> >>>> >>>> Only AccessibleObject.java has changes from the previous version of >>>> this change. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881 >>>> >>>> Thanks, >>>> Coleen >>> Hi Coleen, >>> >>> So hackers are prevented from hacking... >>> >>> Out of curiosity, what would happen if someone changed the classLoader >>> field of some Class object? I guess VM still has it's own notion of >>> the class' class loader, right? Only the code that directly uses the >>> Class.getClassLoader() (and Unsafe.defineClass0) methods would be >>> affected... >> True, Class.getClassLoader() calls would be affected but we may use this >> call for security checks. I'm not really an expert on this, but we >> thought it wouldn't be safe to allow user access to classLoader. >> >>> While we're at it, does this change in any way affect the GC logic? >>> Will GC now navigate the classLoader field during marking but >>> previously didn't ? Will this have any GC performance penalty ? >> I actually ran this through our performance testing and got a good >> improvement in one of the scimark benchmarks for no reason I could >> explain (and lost the results), but none of the other tests were >> affected. GC would have to mark this new field for full collections but >> not young collections because it's only set during initialization. I >> wouldn't expect this field to have any negative performance for GC. > Peter has a good point actually. If the classLoader field is trustworthy we > can get rid of some code in InstanceMirrorKlass::{oop_follow_contents, > oop_oop_iterate} which currently picks up the class loader through the Klass* > field injected into java/lang/Class. It would be a nice simplification if the > ClassLoader objects were the only places where the GC would need to find the > link to the ClassLoaderData metadata. > > But that won't work because anonymous (as in Unsafe.defineAnonymousClass) > classes don't interact with class loaders in the same way and have their own > ClassLoaderData objects. Yes, one version of this patch removed class_loader_data from InstanceKlass so we'd be space-neutral but since there isn't a 1-1 relationship to class_loader and ClassLoaderData for Unsafe anonymous classes, it doesn't work. We might think of a way around this because we want to go in this direction. Thanks, Coleen > > /Mikael > >> Thanks, >> Coleen >> >>> Regards, Peter >>> >>>> On 6/19/14, 11:01 PM, David Holmes wrote: >>>>> On 20/06/2014 6:53 AM, Joel Borggrén-Franck wrote: >>>>>> Hi Mandy, >>>>>> >>>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung(a)oracle.com> wrote: >>>>>>> On 6/19/14 12:34 PM, Joel Borggrén-Franck wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore >>>>>>>> >>>>>>>> <coleen.phillimore(a)oracle.com> wrote: >>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggrén-Franck wrote: >>>>>>>>>> Have you considered hiding the Class.classLoader field from >>>>>>>>>> reflection? I’m not sure it is necessary but I’m not to keen on >>>>>>>>>> the idea of people poking at this field with Unsafe (which >>>>>>>>>> should go away in 9 but …). >>>>>>>>> I don't know how to hide the field from reflection. It's a >>>>>>>>> private final field so you need to get priviledges to make it >>>>>>>>> setAccessible. If you mean injecting it on the JVM side, the >>>>>>>>> reason for this change is so that the JIT compilers can inline >>>>>>>>> this call and not have to call into the JVM to get the class >>>>>>>>> loader. >>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that >>>>>>>> hides a field from being found using reflection. It might very >>>>>>>> well be the case that private and final is enough, I haven’t >>>>>>>> thought this through 100%. On the other hand, is there a reason >>>>>>>> to give users access through the field instead of having to use >>>>>>>> Class.getClassLoader()? >>>>>>> There are many getter methods that returns a private final field. >>>>>>> I'm not sure if hiding the field is necessary nor a good precedence >>>>>>> to set. Accessing a private field requires "accessDeclaredMember" >>>>>>> permission although it's a different security check (vs >>>>>>> "getClassLoader" >>>>>>> permission). Arguably before this new classLoader field, one could >>>>>>> call Class.getClassLoader0() via reflection to get a hold of class >>>>>>> loader. >>>>>>> >>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission >>>>>>> is too coarse-grained? I think the security team is looking into >>>>>>> the improvement in that regards. >>>>>> I think I’m a bit worried about two things, first as you wrote, >>>>>> “accessDeclaredMember” isn’t the same as “getClassLoader”, but >>>>>> since you could get the class loader through getClassLoader0() that >>>>>> shouldn’t be a new issue. >>>>>> >>>>>> The second thing is that IIRC there are ways to set a final field >>>>>> after initialization. I’m not sure we need to care about that >>>>>> either if you need Unsafe to do it. >>>>> Normal reflection can set a final field if you can successfully call >>>>> setAccessible(true) on the Field object. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> cheers >>>>>> /Joel

1 0

RFR: 8047721: @since should have JDK version
by Henry Jen 23 Jun '14

23 Jun '14

Hi, Please review a trivial webrev to add JDK version to @since in a format as Mark suggested[1]. http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/ [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html Appened is the diff as in the webrev. Cheers, Henry diff --git a/src/share/classes/java/lang/Package.java b/src/share/classes/java/lang/Package.java --- a/src/share/classes/java/lang/Package.java +++ b/src/share/classes/java/lang/Package.java @@ -107,6 +107,7 @@ * loader to be found. * * @see ClassLoader#definePackage + * @since 1.2 */ public class Package implements java.lang.reflect.AnnotatedElement { /** diff --git a/src/share/classes/javax/crypto/CipherInputStream.java b/src/share/classes/javax/crypto/CipherInputStream.java --- a/src/share/classes/javax/crypto/CipherInputStream.java +++ b/src/share/classes/javax/crypto/CipherInputStream.java @@ -170,7 +170,7 @@ * @return the next byte of data, or <code>-1</code> if the end of the * stream is reached. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int read() throws IOException { if (ostart >= ofinish) { @@ -196,7 +196,7 @@ * the stream has been reached. * @exception IOException if an I/O error occurs. * @see java.io.InputStream#read(byte[], int, int) - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int read(byte b[]) throws IOException { return read(b, 0, b.length); @@ -217,7 +217,7 @@ * the stream has been reached. * @exception IOException if an I/O error occurs. * @see java.io.InputStream#read() - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int read(byte b[], int off, int len) throws IOException { if (ostart >= ofinish) { @@ -254,7 +254,7 @@ * @param n the number of bytes to be skipped. * @return the actual number of bytes skipped. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public long skip(long n) throws IOException { int available = ofinish - ostart; @@ -277,7 +277,7 @@ * @return the number of bytes that can be read from this input stream * without blocking. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public int available() throws IOException { return (ofinish - ostart); @@ -292,7 +292,7 @@ * stream. * * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void close() throws IOException { if (closed) { @@ -321,7 +321,7 @@ * <code>mark</code> and <code>reset</code> methods. * @see java.io.InputStream#mark(int) * @see java.io.InputStream#reset() - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public boolean markSupported() { return false; diff --git a/src/share/classes/javax/crypto/CipherOutputStream.java b/src/share/classes/javax/crypto/CipherOutputStream.java --- a/src/share/classes/javax/crypto/CipherOutputStream.java +++ b/src/share/classes/javax/crypto/CipherOutputStream.java @@ -114,7 +114,7 @@ * * @param b the <code>byte</code>. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void write(int b) throws IOException { ibuffer[0] = (byte) b; @@ -138,7 +138,7 @@ * @exception NullPointerException if <code>b</code> is null. * @exception IOException if an I/O error occurs. * @see javax.crypto.CipherOutputStream#write(byte[], int, int) - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void write(byte b[]) throws IOException { write(b, 0, b.length); @@ -152,7 +152,7 @@ * @param off the start offset in the data. * @param len the number of bytes to write. * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void write(byte b[], int off, int len) throws IOException { obuffer = cipher.update(b, off, len); @@ -174,7 +174,7 @@ * the cipher's block size, no bytes will be written out. * * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void flush() throws IOException { if (obuffer != null) { @@ -198,7 +198,7 @@ * stream. * * @exception IOException if an I/O error occurs. - * @since JCE1.2 + * @since 1.4, JCE1.2 */ public void close() throws IOException { if (closed) { diff --git a/src/share/classes/javax/naming/InitialContext.java b/src/share/classes/javax/naming/InitialContext.java --- a/src/share/classes/javax/naming/InitialContext.java +++ b/src/share/classes/javax/naming/InitialContext.java @@ -125,7 +125,7 @@ * @see Context * @see NamingManager#setInitialContextFactoryBuilder * NamingManager.setInitialContextFactoryBuilder - * @since JNDI 1.1 / Java 2 Platform, Standard Edition, v 1.3 + * @since 1.3, JNDI 1.1 */ public class InitialContext implements Context {

4 6

JDK9 project: XML/JAXP Approachability / Ease of Use
by huizhe wang 23 Jun '14

23 Jun '14

Hi, We're planning on a jaxp project to address usability issues in the JAXP API. One of the complaints about the JAXP API is the number of lines of code that are needed to implement a simple task. Tasks that should take one or two lines often take ten or twelve lines instead. Consider the following example: File file = new File(FILEPATH + "results.xml"); DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); XPathFactory xf = XPathFactory.newInstance(); XPath xp = xf.newXPath(); xp.setNamespaceContext(new NamespaceContext() { @Override public String getNamespaceURI(String prefix) { return "http://example.com/users/"; } @Override public String getPrefix(String namespaceURI) { return "ns1"; } @Override public Iterator getPrefixes(String namespaceURI) { ArrayList list = new ArrayList(); list.add("ns1"); return list.iterator(); } }); try { DocumentBuilder builder = factory.newDocumentBuilder(); Document document = builder.parse(file); String s = (String) xp.evaluate( "/ns1:Results/ns1:Row[ns1:USERID=2]/ns1:NAME[text()]", document, XPathConstants.STRING); System.out.println("Company: " + s); } catch (ParserConfigurationException e) { //creating DocumentBuilder } catch (SAXException ex) { //parsing } catch (IOException ex) { //parsing } catch (XPathExpressionException ex) { //xpath evaluation } The issues reflected in the above sample include: *1. Too many abstractions* As shown in the above sample, there are multiple layers of abstraction in the DOM and Xpath API: factory, builder, and document, XPathFactory and XPath. *2. Unnecessary Pluggability* The pluggability layer allows easily plugging in third party implementations. However, in many use cases where pluggability is not needed, it becomes the performance bottleneck for the applications. *3. Too many unrelated checked exceptions* There are four unrelated checked exceptions in the above example. None of them is recoverable. ParserConfigurationException actually reflects a design flaw in the DocumentBuilderFactory that allowed setting both a Schema and Schema Language. In practice, Exception is often used to avoid having to catch each of the checked exceptions. *4. Lack of integration* JAXP is an umbrella of several libraries. The sample code above demonstrated the lack of integration among them. First of all, A DOM Document and XPath have to be created separately. Secondly, as in the above case, the Document may be either namespace-aware or unaware, depending on the setting on the DOM Factory, which is unknown to XPath created later. This project may have two aspects: one to provide APIs to get straight to the objects such as DOM Document, and another to provide convenient methods for some common use cases. (*Note that, there is no intention to replace the existing API nor duplicate all of the features.) For the example above, it could potentially be done in a couple of lines (this is just an illustration on how existing APIs could be simplified and may not reflect what the API would look like): String company = XMLDocument.fromFile(FILEPATH + "results.xml") .evalXPath("/Results/Row[USERID=2]/NAME[text()]"); System.out.printf("Company: %s%n", company); We would love to hear from you. Any thoughts, concerns, experiences/complaints would be very welcome. Thanks, Joe

1 0

RFR JDK-5077522 : Duration.compare incorrect for some values
by huizhe wang 23 Jun '14

23 Jun '14

Hi, This is a long time compatibility issue: Duration.compare returns equal for INDETERMINATE relations defined in XML Schema standard (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the following table: Relation P*1Y* > P*364D* <> P*365D* <> P*366D* < P*367D* P*1M* > P*27D* <> P*28D* <> P*29D* <> P*30D* <> P*31D* < P*32D* P*5M* > P*149D* <> P*150D* <> P*151D* <> P*152D* <> P*153D* < P*154D* The order-relation of two Duratoin values x and y is x < y iff s+x < s+y for each qualified datetime s listed below: * 1696-09-01T00:00:00Z * 1697-02-01T00:00:00Z * 1903-03-01T00:00:00Z * 1903-07-01T00:00:00Z The original implementation used Unix epoch, that is, 00:00:00 UTC on 1 January 1970, as s in the above calculation which violated the above specification. A patch during JDK 6 development added correct implementation of the spec, but it was unfortunately added after the original calculation using Epoch time. *The fix to the issue therefore is simply removing the calculation using Epoch time.* I also consolidated the tedious max field value checks into a method called checkMaxValue. *Patch:* http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/ Test: testCompareWithInderterminateRelation: this is a copy of the JCK test that tests INDETERMINATE relations. testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1 second to the original test cases. For example, to the original test: PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y" Below is the test result: Comparing P1Y and P365D: INDETERMINATE Comparing P1Y and P366D: INDETERMINATE Comparing P1M and P28D: INDETERMINATE Comparing P1M and P29D: INDETERMINATE Comparing P1M and P30D: INDETERMINATE Comparing P1M and P31D: INDETERMINATE Comparing P5M and P150D: INDETERMINATE Comparing P5M and P151D: INDETERMINATE Comparing P5M and P152D: INDETERMINATE Comparing P5M and P153D: INDETERMINATE Comparing PT2419200S and P1M: INDETERMINATE Comparing PT2678400S and P1M: INDETERMINATE Comparing PT31536000S and P1Y: INDETERMINATE Comparing PT31622400S and P1Y: INDETERMINATE Comparing PT525600M and P1Y: INDETERMINATE Comparing PT527040M and P1Y: INDETERMINATE Comparing PT8760H and P1Y: INDETERMINATE Comparing PT8784H and P1Y: INDETERMINATE Comparing P365D and P1Y: INDETERMINATE Comparing P1Y and P364D: expected: GREATER actual: GREATER Comparing P1Y and P367D: expected: LESSER actual: LESSER Comparing P1Y2D and P366D: expected: GREATER actual: GREATER Comparing P1M and P27D: expected: GREATER actual: GREATER Comparing P1M and P32D: expected: LESSER actual: LESSER Comparing P1M and P31DT1H: expected: LESSER actual: LESSER Comparing P5M and P149D: expected: GREATER actual: GREATER Comparing P5M and P154D: expected: LESSER actual: LESSER Comparing P5M and P153DT1H: expected: LESSER actual: LESSER Comparing PT2419199S and P1M: expected: LESSER actual: LESSER Comparing PT2678401S and P1M: expected: GREATER actual: GREATER Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER Number of tests passed: 36 Number of tests failed: 0 Thanks, Joe

3 5

RFR : 8047777: Build broken: ProcessEnvironment_md.c not compiling
by Seán Coffey 22 Jun '14

22 Jun '14

The JDK-8036603 fix pushed on Friday broke windows builds. Bad macro call. Simple fix : https://bugs.openjdk.java.net/browse/JDK-8047777 applicable to jdk8u-dev only. > --- a/src/windows/native/java/lang/ProcessEnvironment_md.c > +++ b/src/windows/native/java/lang/ProcessEnvironment_md.c > @@ -41,7 +41,7 @@ > CHECK_NULL_RETURN(string_class, NULL); > String_init_ID = > (*env)->GetMethodID(env, string_class, "<init>", "([B)V"); > - CHECK_NULL_RETURN(String_init_ID); > + CHECK_NULL_RETURN(String_init_ID, NULL); > blockA = (jbyte *) GetEnvironmentStringsA(); > if (blockA == NULL) { > /* Both GetEnvironmentStringsW and GetEnvironmentStringsA regards, Sean.

2 1

ThreadLocalRandom.nextSecondarySeed() re-initializes TLR's seed
by Peter Levart 22 Jun '14

22 Jun '14

Hi, I noticed an inconsistency in calling TLR.localInit() method. Everywhere it's called conditionaly if thread-local "probe" is zero except in TLR.nextSecondarySeed() where it's called if "secondary" seed is zero. This re-initializes the "probe" and "seed" even though they might have already been initialized. It's not a big deal, because this happens at most once per thread, but it would be more consistent to call localInit() conditionaly, I think: diff -r 5b45a5efe417 src/share/classes/java/util/concurrent/ThreadLocalRandom.java --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue May 20 10:11:23 2014 +0400 +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Thu Jun 19 10:34:18 2014 +0200 @@ -1034,7 +1034,8 @@ r ^= r << 5; } else { - localInit(); + if (UNSAFE.getInt(t, PROBE) == 0) + localInit(); if ((r = (int)UNSAFE.getLong(t, SEED)) == 0) r = 1; // avoid zero } Regards, Peter

3 4