Re: RFR: 8000489: older builds of hsdis don't work anymore after 6879063

Thanks. Will update with that. Yumin On 10/24/2012 2:50 PM, serguei.spit...@oracle.com wrote: || Yumin, *src/share/tools/hsdis/hsdis.h: * A typo in the comment: 62 /* This is the compatability interface for older version of hotspot */ => 62 /* This is the compatibility interface

Re: review request: 6533010 SPEC: A few broken links in jvmti.html

Serguei, Does the change to the micro version need to go through approval processes? That aside I don't quite understand how you can just bump the micro version for JDK7 when JDK 7 is already out there with a different micro version. The web version of the spec indicates it is 1.2.1 for JDK 7:

Re: RFR: 8000489: older builds of hsdis don't work anymore after 6879063

On Oct 24, 2012, at 10:01 AM, yumin...@oracle.com wrote: > Hi, all > > Can I have your codereview of 8000489: older builds of hsdis don't work > anymore after 6879063 > It caused old build broke the disassembler. > > Webrev: http://cr.openjdk.java.net/~minqi/8000489 Shouldn't there be a cor

hg: jdk8/tl/jdk: 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c

Changeset: 909676adaefd Author:chegar Date: 2012-10-24 21:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/909676adaefd 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/sol

Re: RFR: 8000489: older builds of hsdis don't work anymore after 6879063

|| Yumin, *src/share/tools/hsdis/hsdis.h: * A typo in the comment: 62 /* This is the compatability interface for older version of hotspot */ => 62 /* This is the compatibility interface for older versions of hotspot */ ||*|src|/share/tools/hsdis/hsdis-demo.c:* Would it make sense to c

Re: RFR: 8000489: older builds of hsdis don't work anymore after 6879063

Krystal, Thanks. Updated in same webrev. I checked b10, the output looks OK /Yumin On 10/24/2012 12:24 PM, Krystal Mok wrote: Hi Yumin, minor typos: s/instrurctions/instructions/ By the way, I tried to use a build of hsdis plugin after 6879063 in an earlier JDK build (e.g. JDK8b59) and

hg: jdk8/tl/jdk: 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated

Changeset: 8e8fcd44b963 Author:jbachorik Date: 2012-10-24 20:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e8fcd44b963 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated Reviewed-by: alanb ! test/javax/management/remote/mandatory/URLT

Re: RFR: 8000489: older builds of hsdis don't work anymore after 6879063

Hi Yumin, minor typos: s/instrurctions/instructions/ By the way, I tried to use a build of hsdis plugin after 6879063 in an earlier JDK build (e.g. JDK8b59) and it was working strangely. A rough look at the output looks like it's missing some newlines, I didn't go into the details. Could you plea

review request: 6533010 SPEC: A few broken links in jvmti.html

Hello, Please, review the fix for (preliminary reviewed by james.holml...@oracle.com) : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6533010 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/6533010-JVMTI-doc Generated jvmti.html: http://javaweb.sfbay.sun.com/java/svc/ss45

Re: [PATCH] JDK-6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject

Jaroslav, I'll sponsor it. Just ping me when the fix passed all reviews. -Dmitry On 2012-10-24 19:49, Eamonn McManus wrote: > This is already Reviewed-by: emcmanus, but I'm afraid I can't sponsor it. > > Éamonn > > > 2012/10/24 Jaroslav Bachorik > > >

RFR: 8000489: older builds of hsdis don't work anymore after 6879063

Hi, all Can I have your codereview of 8000489: older builds of hsdis don't work anymore after 6879063 It caused old build broke the disassembler. Webrev: http://cr.openjdk.java.net/~minqi/8000489 Thanks Yumin

Re: [PATCH] JDK-6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure

The fix looks good, but I would adjust a couple of small things. First, you can improve the existing and new code with multi-catch. Second, the message in the if (notFoundCount > 0) block should be adjusted to take into account the new cases. Finally, hardwiring port 12345 into the test makes it a

Re: [PATCH] JDK-6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject

This is already Reviewed-by: emcmanus, but I'm afraid I can't sponsor it. Éamonn 2012/10/24 Jaroslav Bachorik > I am looking for review and a sponsor. > > Webrev is available at > http://cr.openjdk.java.net/~jbachorik/JDK-6783290/webrev.01/ > > The serialization of javax.management.MBeanInfo a

hg: jdk8/tl/jdk: 8001466: Nightly regression test failure of SSLSocketSNISensitive.java

Changeset: e782f3c383fe Author:xuelei Date: 2012-10-24 08:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e782f3c383fe 8001466: Nightly regression test failure of SSLSocketSNISensitive.java Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISe

Re: jmx-dev [PATCH] JDK-6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated

On 24/10/2012 14:50, Jaroslav Bachorik wrote: I am looking for review and sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6976971/webrev.00 This is a simple fix - just adding back the test that used to fail due to changes in URI spec. The changes were rolled back befor

Re: jmx-dev [PATCH] JDK-6705499: Bad JMXConnectorProvider class name prevents all connections - even with standard RMI connector

On 24/10/2012 15:15, Jaroslav Bachorik wrote: I am looking for review and a sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6705499/webrev.00/ The issue is caused by the way the java.util.ServiceLoader treats the service registration with incorrect class names. Such a

Re: [PATCH] JDK-6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure

Updated webrev at http://cr.openjdk.java.net/~jbachorik/JDK-6937053/webrev.01/ - removed a dangling debug output. -JB- On 10/24/2012 04:03 PM, Jaroslav Bachorik wrote: > I am looking for review and a sponsor. > > Webrev available at > http://cr.openjdk.java.net/~jbachorik/JDK-6937053/webrev.00/

[PATCH] JDK-6705499: Bad JMXConnectorProvider class name prevents all connections - even with standard RMI connector

I am looking for review and a sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6705499/webrev.00/ The issue is caused by the way the java.util.ServiceLoader treats the service registration with incorrect class names. Such a service registration causes java.util.ServiceCon

[PATCH] JDK-6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject

I am looking for review and a sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6783290/webrev.01/ The serialization of javax.management.MBeanInfo and javax.management.MBeanFeatureInfo instances is asymmetrical in cases with no attached descriptor. The descriptor is serial

[PATCH] JDK-6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure

I am looking for review and a sponsor. Webrev available at http://cr.openjdk.java.net/~jbachorik/JDK-6937053/webrev.00/ The RMI marshalling process may throw java.rmi.UnmarshallException eg. in cases of incompatible changes in enums. The bad thing is that ClientNotifForwarder chooses to silently

[PATCH] JDK-6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated

I am looking for review and sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6976971/webrev.00 This is a simple fix - just adding back the test that used to fail due to changes in URI spec. The changes were rolled back before mustang and the test has no reason to fail. T

[PATCH] JDK-7009998: JMX synchronization during connection restart is faulty

I am looking for a review and patch sponsor. Webrev available at http://cr.openjdk.java.net/~jbachorik/JDK-7009998/webrev.00 The issue is about a possible race condition in the ClientCommunicatorAdmin when the reconnection process may be initiated by more than one thread (eg. 3). The main reason