Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

2014-05-13 Thread Paul Sandoz
On May 12, 2014, at 1:00 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: src/share/classes/sun/misc/UUDecoder.java 126 StringBuilder x = new StringBuilder(); Is only filled, but doesn't seem to be used anyhow. Maybe just delete it? Thanks, i will take a look at this and your

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

2014-05-13 Thread Paul Sandoz
On May 12, 2014, at 4:07 PM, Daniel Fuchs daniel.fu...@oracle.com wrote: Hi Paul, I looked at -management and the changes there look good. There is just some two spaces vs four space formatting in

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

2014-05-13 Thread Alan Bateman
On 12/05/2014 11:55, Paul Sandoz wrote: On May 12, 2014, at 12:42 PM, Alan Bateman alan.bate...@oracle.com wrote: On 12/05/2014 11:03, Paul Sandoz wrote: It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. The

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

2014-05-13 Thread Staffan Larsen
On 9 maj 2014, at 20:18, serguei.spit...@oracle.com wrote: Staffan, This is important discovery, thanks! The fix looks good to me. One question below. Thanks, Serguei On 5/9/14 3:47 AM, Staffan Larsen wrote: On 8 maj 2014, at 19:05, Daniel D. Daugherty daniel.daughe...@oracle.com

Re: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately

2014-05-13 Thread Alan Bateman
This is debugger's shared memory transport so cc'ing serviceability-dev as that is there this code is maintained. Is there a test case or any outline of the conditions that cause this? I think that would be useful to understand the issue further. -Alan On 13/05/2014 11:46, Aleksej Efimov

Re: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately

2014-05-13 Thread Aleksej Efimov
Alan, There is no test case for this issue and also the attempt to outline the conditions ended with no result. The report is based only on 'WaitForMultipleObjects' code analysis and this fix is an attempt to make the code looks a little more correct. -Aleksej On 05/13/2014 02:57 PM, Alan

Re: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately

2014-05-13 Thread David Holmes
I don't understand this one at all. What is an abandoned mutex? For that matter why does the code wait on a mutex and an event? Do we already own the mutex? If so what does it mean to wait on it? If not then how can we release it? ??? Thanks, David On 13/05/2014 8:57 PM, Alan Bateman

Re: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately

2014-05-13 Thread Aleksej Efimov
David, The Windows has a different terminology for mutex objects (much differs from the POSIX one). This one link gave me some understanding of it [1]. Here is the MSDN [1] description of what abandoned mutex is: If a thread terminates without releasing its ownership of a mutex object, the

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

2014-05-13 Thread Daniel D. Daugherty
new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp No comments. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No

Re: RFR (S) 8042796: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found

2014-05-13 Thread Daniel D. Daugherty
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 src/share/vm/oops/method.hpp No comments. src/share/vm/utilities/accessFlags.hpp line 57: JVM_ACC_ON_STACK= 0x0008, // RedefinedClasses() is used on the stack Typos:

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

2014-05-13 Thread serguei.spit...@oracle.com
On 5/13/14 2:20 AM, Staffan Larsen wrote: On 9 maj 2014, at 20:18, serguei.spit...@oracle.com mailto:serguei.spit...@oracle.com wrote: Staffan, This is important discovery, thanks! The fix looks good to me. One question below. Thanks, Serguei On 5/9/14 3:47 AM, Staffan Larsen wrote: On

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

2014-05-13 Thread Christian Thalinger
Since: int _interp_only_mode; is an int field I would prefer to actually read the value as an int instead of just a byte on x86: +__ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); Otherwise this looks good. On May 13, 2014, at 11:30 AM, Staffan Larsen

Re: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately

2014-05-13 Thread David Holmes
Hi Aleksej, Thanks for the doc references regarding abandonment. Let me rephrase my question. What is this logic trying to achieve by waiting on both a mutex and an event? Do we already own the mutex when this function is called? David On 13/05/2014 11:19 PM, Aleksej Efimov wrote: David,