Re: Codereview request: 8025204 Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java

Shanliang writes: Hi, Simply wait longer time for a broken notif. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8025205 ! // no deadline here, let's wait till either the connId is removed ! // or the

Re: Codereview request: 8025205 Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java

Shanliang writes: Hi, Simply wait longer time for a broken notif. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8025205 The new loop seems okay - and there is a println to aid in the timeout case. Not sure about the extra Thread.slee

Re: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java

Shanliang writes: Daniel Fuchs wrote: Hi Shanliang, Shouldn't 'messageReceived' be at least declared as volatile? It looks as if this test is a multi-thread test which is not MT-safe. OK I am convinced: http://cr.openjdk.java.net/~sjiang/JDK-8025206/02/ The volatile is definitely needed

Re: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java

shanliang wrote: Daniel Fuchs wrote: On 9/23/13 8:27 PM, shanliang wrote: Hi, Please review this test fix, if the test continues failing, then we need to investigate the Monitor implementation. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ bug: https://bugs.openjdk.java.net/brows

hg: jdk8/tl/jdk: 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs

Changeset: f1e31376f419 Author:robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4

Re: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to

On 10/8/13 3:54 PM, Coleen Phillimore wrote: Hi Serguei, Thanks again for the prompt code review. On 10/08/2013 04:56 PM, serguei.spit...@oracle.com wrote: It looks good. A question: 1011 case JVM_CONSTANT_MethodType: 1012 { 1013 int k1 = method_type_index_at_error_ok(index1); 1014

Re: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to

Hi Serguei, Thanks again for the prompt code review. On 10/08/2013 04:56 PM, serguei.spit...@oracle.com wrote: It looks good. A question: 1011 case JVM_CONSTANT_MethodType: 1012 { 1013 int k1 = method_type_index_at_error_ok(index1); 1014 int k2 = cp2->method_type_index_at_error_ok

Re: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611)

Sorry for the delay in getting back to this. I've been side tracked by other tasks. I've made all the changes needed to address most of the comments below, but I still have to double check and test... On 10/1/13 8:52 PM, David Holmes wrote: Hi Dan, Overall thumbs up. Thanks! A couple of

hg: hsx/hotspot-rt/hotspot: 8026022: Verifier: allow anon classes to invokespecial host class/intf methods.

Changeset: c72075c2883e Author:acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifie

Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative values

On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: On 8.10.2013 09:34, David Holmes wrote: Jaroslav, On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: Hello, currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS

Re: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to

It looks good. A question: 1011 case JVM_CONSTANT_MethodType: 1012 { 1013 int k1 = method_type_index_at_error_ok(index1); 1014 int k2 = cp2->method_type_index_at_error_ok(index2); . . . 1021 case JVM_CONSTANT_MethodHandle: 1022 { 1023 int k1 = method_handle_ref_kind_at_error_o

Re: RFR [8025886] typo in shell regtest == instead of =

Thanks, Dmitry! I assume I still need an approval from the Reviewer. Sincerely yours, Ivan On 05.10.2013 21:30, Dmitry Samersoff wrote: Ivan, Looks good for me. -Dmitry On 2013-10-05 17:04, Ivan Gerasimov wrote: Dmitry, thanks for suggestion! Yes, == comparison isn't the only sh-incompati

RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to

Summary: Add missing cases. I verified this with the test for https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to copy the test into with modifications the hotspot repository, still working on refactoring the test for the JDK repository for after this gets pushed. open webrev

Re: Fix to 8025925

Hello. I prepared a little fix to JDK-8025925 . Find webrev here please: http://cr.openjdk.java.net/~iignatyev/atimofeev/8025925/webrev.00/index.html (now it's o

Re: RFR (S): 8025427 jstat tests fails on 32-bit platforms

Thanks Serguei! Still need an official Reviewer. Thanks, /Staffan On 8 okt 2013, at 17:24, serguei.spit...@oracle.com wrote: > Looks good. > > Thanks, > Serguei > > On 10/8/13 5:06 AM, Staffan Larsen wrote: >> Pinging again: Please, pretty please? :) >> >> /Staffan >> >> On 1 okt 2013, at 2

hg: jdk8/tl/jaxp: 2 new changesets

Changeset: dbecbb685503 Author:mfang Date: 2013-10-08 09:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dbecbb685503 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java !

hg: jdk8/tl/nashorn: 6 new changesets

Changeset: 6345d08fd5de Author:hannesw Date: 2013-10-08 11:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6345d08fd5de 8025213: Assignment marks variable as defined too early Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java + test/s

Re: RFR (S): 8025427 jstat tests fails on 32-bit platforms

Looks good. Thanks, Serguei On 10/8/13 5:06 AM, Staffan Larsen wrote: Pinging again: Please, pretty please? :) /Staffan On 1 okt 2013, at 20:46, Staffan Larsen wrote: Any Reviewer who can take a look? Thanks, /Staffan On 27 sep 2013, at 23:59, Staffan Larsen wrote: This change makes j

Re: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64

Yes, I can see that reasoning. I have the opposite perspective though: I think it is the matter of user experience, RuntimeMXBean should not care about the launcher/VM distinction, since what user "perceives" is the JVM launched via "java". Segregating the launcher and "pure" VM options seems to b

Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative values

On 8.10.2013 09:34, David Holmes wrote: Jaroslav, On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: Hello, currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization

Re: RFR (S): 8025427 jstat tests fails on 32-bit platforms

Pinging again: Please, pretty please? :) /Staffan On 1 okt 2013, at 20:46, Staffan Larsen wrote: > Any Reviewer who can take a look? > > Thanks, > /Staffan > > On 27 sep 2013, at 23:59, Staffan Larsen wrote: > >> This change makes jstat output '-' instead of '\ufffd' when the result of a >

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: c90e76575b03 Author:kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.

Re: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out

On 8.10.2013 05:42, David Holmes wrote: Jaroslav, Can you summarise the changes please? With the conversion to Java and the infrastructure additions I can't tell what is actually fixing the original timeout issue :) The timeout was most caused by using the same file for communication between

hg: jdk8/tl/jdk: 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers

Changeset: 95bb56c61276 Author:alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.

hg: jdk8/tl/jdk: 8025136: SplittableRandom enchancements

Changeset: b90dcd1a71bf Author:psandoz Date: 2013-10-08 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90dcd1a71bf 8025136: SplittableRandom enchancements Reviewed-by: psandoz, martin Contributed-by: Doug Lea , Guy Steele ! src/share/classes/java/util/Random.java !

hg: hsx/hotspot-rt/hotspot: 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use

Changeset: 615d83933195 Author:dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.ch...@

Review request: 8025996: Track metaspace usage when metaspace is expanded

http://cr.openjdk.java.net/~stefank/8025996/webrev.00 Previously, the Metaspace memory usage was only tracked at the end of the GCs. This causes the MemoryPoolMXBean.getUsageThreshold(…) functionality to fail for the Metaspace memory pools. This patch adds tracking of Metaspace usage when a ne

Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative values

Jaroslav, On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: Hello, currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization etc.). The uptime should not depend on t