Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

On Dec 14, 2015, at 9:53 AM, Marcus Larsson wrote: > > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ One minor nit:

RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

Hi, Please review the following patch to use a semaphore instead of a mutex for the synchronization of log configuration. Using a mutex requires some parts of the VM to be initialized, whereas the semaphores can be used right from the start. This simplifies the code and allows very early log

Re: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request

Hi, On 14.12.2015 08:32, Harsha Wardhana B wrote: Hi All, Please review the fix for bug, Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 The fix synchronizes access to requestList of

Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

Hi again, Made some changes to the patch after feedback from Markus Grönlund. The ConfigurationLocker and the semaphore have been moved out of the LogConfiguration.hpp and into the .cpp instead. The lock is only used internally by the LogConfiguration so this makes sense. It simplifies the

RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy

Hi, Please review this fix for dumping of long arrays, and general cleanup of types in heapDumper.cpp. Problem: At several places in heapDumper.cpp overflows could happen when dumping long arrays. Also the hprof format uses an u4 as a record length field, but arrays can be longer than that

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

I really wish we had some view inside windows to see exactly what is going wrong here. :( On 15/12/2015 12:09 AM, Ivan Gerasimov wrote: Hello! There was a timeout observed in os_windows.cpp at the line 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, handles, FALSE,

Re: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

Hi Jaroslav, This movement of functionality seems okay to me. And good to see the JDK 6 code removed :) Thanks, David On 15/12/2015 2:55 AM, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev:

Re: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

> On Dec 14, 2015, at 8:55 AM, Jaroslav Bachorik > wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 > Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 > > The problem is that the class

Re: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

On 14/12/2015 16:55, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class UsageTrackerClient is accessing

RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

Hello! There was a timeout observed in os_windows.cpp at the line 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, handles, FALSE, EXIT_TIMEOUT); This means there were more than 64 threads exiting at the same time and none of the first 64 threads could make any progress

Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

Hi Marcus, Looks good! On 14/12/2015 8:13 PM, Marcus Larsson wrote: Hi, Please review the following patch to use a semaphore instead of a mutex for the synchronization of log configuration. Using a mutex requires some parts of the VM to be initialized, whereas the semaphores can be used right

Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

Hi David, On 2015-12-14 13:53, David Holmes wrote: Hi Marcus, Looks good! Thanks! On 14/12/2015 8:13 PM, Marcus Larsson wrote: Hi, Please review the following patch to use a semaphore instead of a mutex for the synchronization of log configuration. Using a mutex requires some parts of

Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

Hi, New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ Changes: * Introduced the ConfigurationLocker class for automatic wait/signal in constructor/destructor just like a MutexLocker. * Added an assert to

RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class UsageTrackerClient is accessing RuntimeMXBean.getInputArguments() method via reflection to avoid static

Re: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy

Andreas, Nice cleanup. Some generic comments below. 1. It would be excellent if you can split webrev into two parts, one part with types cleanup and other part with array truncation related changes or ever push these changes separately as it address different problems. Type cleanup could be

Re: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy

Hi Dmitry, thanks for looking at this. On 2015-12-14 18:30, Dmitry Samersoff wrote: Andreas, Nice cleanup. Some generic comments below. 1. It would be excellent if you can split webrev into two parts, one part with types cleanup and other part with array truncation related changes or ever

RE: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration

Hi Marcus, Thanks for updating the patch. I think you could also move the lock representation, i.e the Semaphore to become a (static) field inside the ConfigurationLocker class - this since you want all entry/exits to go through instances of this object. I know that the other MutexLocker's