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

On May 12, 2014, at 1:00 PM, Ivan Gerasimov 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 other change once s/S

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

On May 12, 2014, at 4:07 PM, Daniel Fuchs 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

On 12/05/2014 11:55, Paul Sandoz wrote: On May 12, 2014, at 12:42 PM, Alan Bateman 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 groupings are a bit odd Ye

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

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 >> wrote: >>

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

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 w

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

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 Ba

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

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 wrot

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

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, th

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

> 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 comm

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

> 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: 'Redef

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

On 13 maj 2014, at 18:53, Daniel D. Daugherty wrote: > > 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

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

On 5/13/14 2:20 AM, Staffan Larsen wrote: 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: O

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

Dan, Thank you a lot for reviewing! On 5/13/14 10:42 AM, Daniel D. Daugherty wrote: > 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

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

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

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,

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

Thanks Christian, I will make the change below before I push. /Staffan diff --git a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp @@ -2248,7 +2248,7 @@ // if we