From jaroslav.bachorik at oracle.com  Mon Nov  4 05:07:10 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 04 Nov 2013 14:07:10 +0100
Subject: jmx-dev RFR 8027163:
 sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be
 updated for jdk8 removal of solaris-32bit support
Message-ID: <52779BFE.1080704@oracle.com>

Please, review the following test change:

Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/

Currently, the test is designed to work only on solaris-32bit. With the 
support removed it is necessary to adapt the test as well. This includes 
generating the solaris-sparcv9 and solaris-amd64 binaries for the 
launcher the test is using.

The test itself needs changing the way it retrieves the ARCH name for 
sparcv9 architecture. Also, since it is forbidden to check in any files 
with executable permissions the test must account for this and adjust 
the file permissions temporarily while executing. It needs to revert to 
the original permissions when it's finished to prevent reporting the 
launcher files as modified in HG.

While testing the changes the 
sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing 
intermittently (50%) when run in agentvm mode together with 
CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests 
to run in othervm mode seems to fix the problem.

There is a small debugging improvement in 
ProcessTools.java#startProcess() method - when the phaser timesout or is 
interrupted all the stack traces are dumped to stderr to help diagnosing 
any locking situations.

Thanks,

-JB-

From erik.gahlin at oracle.com  Tue Nov  5 07:57:36 2013
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 05 Nov 2013 16:57:36 +0100
Subject: jmx-dev RFR: 8027209:
 javax/management/monitor/ThreadPoolAccTest.java fails intermittently
In-Reply-To: <5271141C.3030400@oracle.com>
References: <5271141C.3030400@oracle.com>
Message-ID: <52791570.50602@oracle.com>

Could I have a review of this intermittently failing test.

Instead of doing Thread.sleep(2000) and assume principal is visible/set 
the test now spins until principal is available. I also cleaned up code 
to avoid warnings.

Thanks
Erik

Webrev:
http://cr.openjdk.java.net/~egahlin/8027209_3/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8027209

From erik.gahlin at oracle.com  Tue Nov  5 08:25:47 2013
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 05 Nov 2013 17:25:47 +0100
Subject: jmx-dev RFR: 6543856: MonitorVmStartTerminate.sh fails
	intermittently
Message-ID: <52791C0B.9010101@oracle.com>

Could I please have a review of this intermittently failing test.

Removed Thread.sleep and instead used two count down latches. Also did 
some cleaning up; removed an unused import, added generics etc.

Thanks
Erik

Webrev:
http://cr.openjdk.java.net/~egahlin/6543856_1/

Bug:
https://bugs.openjdk.java.net/browse/JDK-6543856

From jaroslav.bachorik at oracle.com  Tue Nov  5 08:30:05 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 05 Nov 2013 17:30:05 +0100
Subject: jmx-dev RFR: 8027209:
 javax/management/monitor/ThreadPoolAccTest.java fails intermittently
In-Reply-To: <52791570.50602@oracle.com>
References: <5271141C.3030400@oracle.com> <52791570.50602@oracle.com>
Message-ID: <52791D0D.60809@oracle.com>

L49-51 The test declaration should go to the original block @ L25-32
L135 You could better use PrivilegedAction<Void> since the return value 
is effectively discarded

The rest looks fine.

-JB-

On 5.11.2013 16:57, Erik Gahlin wrote:
> Could I have a review of this intermittently failing test.
>
> Instead of doing Thread.sleep(2000) and assume principal is visible/set
> the test now spins until principal is available. I also cleaned up code
> to avoid warnings.
>
> Thanks
> Erik
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8027209_3/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8027209


From erik.gahlin at oracle.com  Tue Nov  5 09:15:22 2013
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 05 Nov 2013 18:15:22 +0100
Subject: jmx-dev RFR: 8027209:
 javax/management/monitor/ThreadPoolAccTest.java fails intermittently
In-Reply-To: <52791D0D.60809@oracle.com>
References: <5271141C.3030400@oracle.com> <52791570.50602@oracle.com>
	<52791D0D.60809@oracle.com>
Message-ID: <527927AA.6080600@oracle.com>

Thanks for the review, here is an updated webrev.

http://cr.openjdk.java.net/~egahlin/8027209_4/

Erik

Jaroslav Bachorik skrev 2013-11-05 17:30:
> L49-51 The test declaration should go to the original block @ L25-32
> L135 You could better use PrivilegedAction<Void> since the return 
> value is effectively discarded
>
> The rest looks fine.
>
> -JB-
>
> On 5.11.2013 16:57, Erik Gahlin wrote:
>> Could I have a review of this intermittently failing test.
>>
>> Instead of doing Thread.sleep(2000) and assume principal is visible/set
>> the test now spins until principal is available. I also cleaned up code
>> to avoid warnings.
>>
>> Thanks
>> Erik
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8027209_3/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8027209
>


From staffan.larsen at oracle.com  Tue Nov  5 10:15:52 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 5 Nov 2013 13:15:52 -0500
Subject: jmx-dev RFR: 8027209:
	javax/management/monitor/ThreadPoolAccTest.java fails intermittently
In-Reply-To: <527927AA.6080600@oracle.com>
References: <5271141C.3030400@oracle.com> <52791570.50602@oracle.com>
	<52791D0D.60809@oracle.com> <527927AA.6080600@oracle.com>
Message-ID: <457E1EBC-1301-4425-B5E5-5124E6728941@oracle.com>

Looks good!

Thanks,
/Staffan

On 5 nov 2013, at 12:15, Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Thanks for the review, here is an updated webrev.
> 
> http://cr.openjdk.java.net/~egahlin/8027209_4/
> 
> Erik
> 
> Jaroslav Bachorik skrev 2013-11-05 17:30:
>> L49-51 The test declaration should go to the original block @ L25-32
>> L135 You could better use PrivilegedAction<Void> since the return value is effectively discarded
>> 
>> The rest looks fine.
>> 
>> -JB-
>> 
>> On 5.11.2013 16:57, Erik Gahlin wrote:
>>> Could I have a review of this intermittently failing test.
>>> 
>>> Instead of doing Thread.sleep(2000) and assume principal is visible/set
>>> the test now spins until principal is available. I also cleaned up code
>>> to avoid warnings.
>>> 
>>> Thanks
>>> Erik
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~egahlin/8027209_3/
>>> 
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8027209
>> 
> 


From staffan.larsen at oracle.com  Tue Nov  5 10:16:42 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 5 Nov 2013 13:16:42 -0500
Subject: jmx-dev RFR: 6959636: testcase failing on windows
	javax/management/loading/LibraryLoader/LibraryLoaderTest.java,
In-Reply-To: <52790EB8.1040907@oracle.com>
References: <52790EB8.1040907@oracle.com>
Message-ID: <66E97D56-9139-415C-99E2-0B6D1F760D70@oracle.com>

Looks good!

Thanks,
/Staffan


On 5 nov 2013, at 10:28, Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Could I please have a review, fix is to run test in separate vm.
> 
> I also removed warnings and allowed the exception to propagate.
> 
> Thanks
> Erik
> 
> Webrev:
> http://cr.openjdk.java.net/~egahlin/6959636_1/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6959636
> 
> 


From staffan.larsen at oracle.com  Tue Nov  5 10:23:34 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 5 Nov 2013 13:23:34 -0500
Subject: jmx-dev RFR: 6543856: MonitorVmStartTerminate.sh fails
	intermittently
In-Reply-To: <52791C0B.9010101@oracle.com>
References: <52791C0B.9010101@oracle.com>
Message-ID: <242E126D-BF7F-44EB-8531-9D996CBDCF5E@oracle.com>

Looks good!

Thanks,
/Staffan

On 5 nov 2013, at 11:25, Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Could I please have a review of this intermittently failing test.
> 
> Removed Thread.sleep and instead used two count down latches. Also did some cleaning up; removed an unused import, added generics etc.
> 
> Thanks
> Erik
> 
> Webrev:
> http://cr.openjdk.java.net/~egahlin/6543856_1/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6543856


From david.holmes at oracle.com  Tue Nov  5 16:52:37 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 06 Nov 2013 10:52:37 +1000
Subject: jmx-dev RFR: 6543856: MonitorVmStartTerminate.sh fails
	intermittently
In-Reply-To: <242E126D-BF7F-44EB-8531-9D996CBDCF5E@oracle.com>
References: <52791C0B.9010101@oracle.com>
	<242E126D-BF7F-44EB-8531-9D996CBDCF5E@oracle.com>
Message-ID: <527992D5.50408@oracle.com>

Hi Erik,

 From what I can see this test will no longer try to check that the 
number of sleepers started and terminated are valid - it will either 
pass or hang (because the latches do not release) - relying on the test 
harness to time it out (ditto for the removal of the timeout from the 
ss.join()). It seems to me that you could have simplified the changes 
(and kept the existing failure modes) if you had simply added a 
semaphore.acquire in main after ss.join and before listener.getStarted; 
with the semaphore release at the end of vmStatusChanged. But what you 
have isn't wrong.

Aside: The CountDownLatch usage is a little odd as the typical pattern 
is that different threads call countDown. The same semantics could have 
been achieved with a Semaphore initialized to zero and using 
acquire(count) and release(recentlyTerminated) etc.

Two minor nits:

- for(Integer lvmid : list)  - need space after for (line 92 and 207)

- waitForSleeperToStart() should be waitForSleepersToStart (plural to 
match termination function).

Otherwise good to go (unless you choose to revisit the approach taken :) ).

Thanks,
David

On 6/11/2013 4:23 AM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 5 nov 2013, at 11:25, Erik Gahlin <erik.gahlin at oracle.com> wrote:
>
>> Could I please have a review of this intermittently failing test.
>>
>> Removed Thread.sleep and instead used two count down latches. Also did some cleaning up; removed an unused import, added generics etc.
>>
>> Thanks
>> Erik
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/6543856_1/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-6543856
>

From jaroslav.bachorik at oracle.com  Thu Nov  7 06:01:45 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 07 Nov 2013 15:01:45 +0100
Subject: jmx-dev RFR: 8004126: TEST_BUG: com/sun/jdi/BadHandshakeTest.java
	fails intermittently
Message-ID: <527B9D49.5010908@oracle.com>

Please, review this test fix.

Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00

The failure was caused by the IOHandler not waiting for the actual 
message stating the the debugee was ready. The patch uses the library 
functions to start the debugee and wait for the actual message to 
appear. Also, it detects problems while starting the debugee and reports 
them instead of failing only when the debugger can not connect.

Thanks,

-JB-

From jaroslav.bachorik at oracle.com  Thu Nov  7 06:29:35 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 07 Nov 2013 15:29:35 +0100
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527BA29C.80302@oracle.com>
References: <527B9D49.5010908@oracle.com> <527BA29C.80302@oracle.com>
Message-ID: <527BA3CF.7090903@oracle.com>

On 7.11.2013 15:24, Yekaterina Kantserova wrote:
> Hi,
>
> would you like to use JDKToolLauncher instead of JdkFinder? The
> JdkFinder will be removed soon (RFR (S): 8015497: Take new fixes from
> hotspot/test/testlibrary to jdk/test/lib/testlibrary).
>
> The example how to use can be found in
> sun/management/jmxremote/bootstrap/LocalManagementTest.java.

Why not. But I will need to wait till your changes are in ...

-JB-

>
> Thanks,
> Katja
>
>
>
> On 11/07/2013 03:01 PM, Jaroslav Bachorik wrote:
>> Please, review this test fix.
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>>
>> The failure was caused by the IOHandler not waiting for the actual
>> message stating the the debugee was ready. The patch uses the library
>> functions to start the debugee and wait for the actual message to
>> appear. Also, it detects problems while starting the debugee and
>> reports them instead of failing only when the debugger can not connect.
>>
>> Thanks,
>>
>> -JB-
>


From jaroslav.bachorik at oracle.com  Thu Nov  7 07:41:32 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 07 Nov 2013 16:41:32 +0100
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527BA4E4.7070102@oracle.com>
References: <527B9D49.5010908@oracle.com> <527BA29C.80302@oracle.com>
	<527BA3CF.7090903@oracle.com> <527BA4E4.7070102@oracle.com>
Message-ID: <527BB4AC.1050107@oracle.com>

On 7.11.2013 15:34, Yekaterina Kantserova wrote:
> On 11/07/2013 03:29 PM, Jaroslav Bachorik wrote:
>> On 7.11.2013 15:24, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> would you like to use JDKToolLauncher instead of JdkFinder? The
>>> JdkFinder will be removed soon (RFR (S): 8015497: Take new fixes from
>>> hotspot/test/testlibrary to jdk/test/lib/testlibrary).
>>>
>>> The example how to use can be found in
>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java.
>>
>> Why not. But I will need to wait till your changes are in ...
>
> Sorry, ProcessBuilder's createJavaProcessBuilder() of course, which in
> turn uses JDKToolLauncher.
>
> If you'll use ProcessBuilder's createJavaProcessBuilder() you don't need
> to wait. Before my fix it will use JdkFinder and after it JDKToolLauncher.

Ok. Switched to ProcessTools.createJavaProcessBuilder(). Thanks for the tip.

http://cr.openjdk.java.net/~jbachorik/8004126/webrev.01

-JB-

>
> // Katja
>
>>
>> -JB-
>>
>>>
>>> Thanks,
>>> Katja
>>>
>>>
>>>
>>> On 11/07/2013 03:01 PM, Jaroslav Bachorik wrote:
>>>> Please, review this test fix.
>>>>
>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>>>>
>>>> The failure was caused by the IOHandler not waiting for the actual
>>>> message stating the the debugee was ready. The patch uses the library
>>>> functions to start the debugee and wait for the actual message to
>>>> appear. Also, it detects problems while starting the debugee and
>>>> reports them instead of failing only when the debugger can not connect.
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>>
>


From david.holmes at oracle.com  Thu Nov  7 16:55:25 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 08 Nov 2013 10:55:25 +1000
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527B9D49.5010908@oracle.com>
References: <527B9D49.5010908@oracle.com>
Message-ID: <527C367D.3040401@oracle.com>

On 8/11/2013 12:01 AM, Jaroslav Bachorik wrote:
> Please, review this test fix.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>
> The failure was caused by the IOHandler not waiting for the actual
> message stating the the debugee was ready.

So the base problem was that the initial in.read(b, 0, 100) might not 
actually read the message that the debuggee was ready?

The cleanup seems good to me in general. Only concern I have is that 
where the IOHandler would print what was read (which might not be what 
was expected), in the new code if we don't see what we expect we just 
set a boolean to false and the actual output from the debugee is never 
shown - or is the debuggee output captured elsewhere?

Thanks,
David

  The patch uses the library
> functions to start the debugee and wait for the actual message to
> appear. Also, it detects problems while starting the debugee and reports
> them instead of failing only when the debugger can not connect.
>
> Thanks,
>
> -JB-

From jaroslav.bachorik at oracle.com  Thu Nov  7 23:11:25 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 7 Nov 2013 23:11:25 -0800 (PST)
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527C367D.3040401@oracle.com>
References: <527B9D49.5010908@oracle.com> <527C367D.3040401@oracle.com>
Message-ID: <527C8E9D.1030708@oracle.com>

On 8.11.2013 01:55, David Holmes wrote:
> On 8/11/2013 12:01 AM, Jaroslav Bachorik wrote:
>> Please, review this test fix.
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>>
>> The failure was caused by the IOHandler not waiting for the actual
>> message stating the the debugee was ready.
>
> So the base problem was that the initial in.read(b, 0, 100) might not
> actually read the message that the debuggee was ready?

It would read the message. But the synchronization could get confused by 
an extraneous output before the "ready" message. This is only my best 
guess because I was not able to reproduce the error. But looking at the 
test this is the only path that could lead to SocketException short of 
the debugee application being killed immediately after it has been started.

>
> The cleanup seems good to me in general. Only concern I have is that
> where the IOHandler would print what was read (which might not be what
> was expected), in the new code if we don't see what we expect we just
> set a boolean to false and the actual output from the debugee is never
> shown - or is the debuggee output captured elsewhere?

ProcessTools.startProcess() takes care of forwarding the stderr and 
stdout from the external process to the stderr and stdout of the 
launching app. It also adds a disambiguation prefix to the forwarded logs.

-JB-

>
> Thanks,
> David
>
>   The patch uses the library
>> functions to start the debugee and wait for the actual message to
>> appear. Also, it detects problems while starting the debugee and reports
>> them instead of failing only when the debugger can not connect.
>>
>> Thanks,
>>
>> -JB-


From roger.riggs at oracle.com  Mon Nov 11 14:20:55 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 11 Nov 2013 17:20:55 -0500
Subject: jmx-dev RFR Doclint cleanup of javax.management
In-Reply-To: <527C033D.1080302@oracle.com>
References: <527C033D.1080302@oracle.com>
Message-ID: <52815847.9070304@oracle.com>

Please review and comment.

This changeset addresses the warnings and errors of doclint and
improves the quality of the generated html.
No spec or implementation is changed by this changeset

The changes address issues including html syntax, accessibility issues,
and html tag improper use and list structure.
Refer to the error log attached to the bug report [1] for details.

Please review:
    http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/

Thanks, Roger

[1] https://bugs.openjdk.java.net/browse/JDK-8028014


From jaroslav.bachorik at oracle.com  Tue Nov 12 01:48:17 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 12 Nov 2013 10:48:17 +0100
Subject: jmx-dev RFR Doclint cleanup of javax.management
In-Reply-To: <52815847.9070304@oracle.com>
References: <527C033D.1080302@oracle.com> <52815847.9070304@oracle.com>
Message-ID: <5281F961.9090502@oracle.com>

Hi Roger,

The following comments are based on the presumption that the contained 
HTML should be well-formed.

src/share/classes/javax/management/MBeanFeatureInfo.java
L183, L231 - missing </p>

src/share/classes/javax/management/MBeanInfo.java
L640, L686 - missing </p>

src/share/classes/javax/management/MBeanServerConnection.java
L630 - missing </p>

src/share/classes/javax/management/MBeanServerNotification.java
L89 - missing </p>

src/share/classes/javax/management/MXBean.java
L788 - missing </p>

src/share/classes/javax/management/ObjectName.java
L198 - missing </p>
L204 - missing </p>
L1552 - missing </p>

src/share/classes/javax/management/PersistentMBean.java
L78 - missing </p><p>
L79 - there should be <pre> after this line
L83 - should be * }</PRE></p>

src/share/classes/javax/management/loading/MLet.java
L154 - extraneous </dd>

src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java
L130 - missing </p>

src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
L83 - missing </p>

src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java
L123 - missing </p>

src/share/classes/javax/management/remote/JMXConnector.java
L79 - missing </p>

src/share/classes/javax/management/remote/rmi/RMIConnector.java
L1697 - missing </li> after this line
L1701 - missing </li> after this line

-JB-

On 11.11.2013 23:20, roger riggs wrote:
> Please review and comment.
>
> This changeset addresses the warnings and errors of doclint and
> improves the quality of the generated html.
> No spec or implementation is changed by this changeset
>
> The changes address issues including html syntax, accessibility issues,
> and html tag improper use and list structure.
> Refer to the error log attached to the bug report [1] for details.
>
> Please review:
>     http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/
>
> Thanks, Roger
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8028014
>


From erik.gahlin at oracle.com  Tue Nov  5 07:28:56 2013
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 05 Nov 2013 16:28:56 +0100
Subject: jmx-dev RFR: 6959636: testcase failing on windows
	javax/management/loading/LibraryLoader/LibraryLoaderTest.java,
Message-ID: <52790EB8.1040907@oracle.com>

Could I please have a review, fix is to run test in separate vm.

I also removed warnings and allowed the exception to propagate.

Thanks
Erik

Webrev:
http://cr.openjdk.java.net/~egahlin/6959636_1/

Bug:
https://bugs.openjdk.java.net/browse/JDK-6959636



From yekaterina.kantserova at oracle.com  Thu Nov  7 06:24:28 2013
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 07 Nov 2013 15:24:28 +0100
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527B9D49.5010908@oracle.com>
References: <527B9D49.5010908@oracle.com>
Message-ID: <527BA29C.80302@oracle.com>

Hi,

would you like to use JDKToolLauncher instead of JdkFinder? The 
JdkFinder will be removed soon (RFR (S): 8015497: Take new fixes from 
hotspot/test/testlibrary to jdk/test/lib/testlibrary).

The example how to use can be found in 
sun/management/jmxremote/bootstrap/LocalManagementTest.java.

Thanks,
Katja



On 11/07/2013 03:01 PM, Jaroslav Bachorik wrote:
> Please, review this test fix.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>
> The failure was caused by the IOHandler not waiting for the actual 
> message stating the the debugee was ready. The patch uses the library 
> functions to start the debugee and wait for the actual message to 
> appear. Also, it detects problems while starting the debugee and 
> reports them instead of failing only when the debugger can not connect.
>
> Thanks,
>
> -JB-


From yekaterina.kantserova at oracle.com  Thu Nov  7 06:30:29 2013
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 07 Nov 2013 15:30:29 +0100
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527BA29C.80302@oracle.com>
References: <527B9D49.5010908@oracle.com> <527BA29C.80302@oracle.com>
Message-ID: <527BA405.7020507@oracle.com>

Sorry,  ProcessBuilder's createJavaProcessBuilder() of course, which in 
turn uses JDKToolLauncher.

// Katja

On 11/07/2013 03:24 PM, Yekaterina Kantserova wrote:
> Hi,
>
> would you like to use JDKToolLauncher instead of JdkFinder? The 
> JdkFinder will be removed soon (RFR (S): 8015497: Take new fixes from 
> hotspot/test/testlibrary to jdk/test/lib/testlibrary).
>
> The example how to use can be found in 
> sun/management/jmxremote/bootstrap/LocalManagementTest.java.
>
> Thanks,
> Katja
>
>
>
> On 11/07/2013 03:01 PM, Jaroslav Bachorik wrote:
>> Please, review this test fix.
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>>
>> The failure was caused by the IOHandler not waiting for the actual 
>> message stating the the debugee was ready. The patch uses the library 
>> functions to start the debugee and wait for the actual message to 
>> appear. Also, it detects problems while starting the debugee and 
>> reports them instead of failing only when the debugger can not connect.
>>
>> Thanks,
>>
>> -JB-
>


From yekaterina.kantserova at oracle.com  Thu Nov  7 06:34:12 2013
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 07 Nov 2013 15:34:12 +0100
Subject: jmx-dev RFR: 8004126: TEST_BUG:
 com/sun/jdi/BadHandshakeTest.java fails intermittently
In-Reply-To: <527BA3CF.7090903@oracle.com>
References: <527B9D49.5010908@oracle.com> <527BA29C.80302@oracle.com>
	<527BA3CF.7090903@oracle.com>
Message-ID: <527BA4E4.7070102@oracle.com>

On 11/07/2013 03:29 PM, Jaroslav Bachorik wrote:
> On 7.11.2013 15:24, Yekaterina Kantserova wrote:
>> Hi,
>>
>> would you like to use JDKToolLauncher instead of JdkFinder? The
>> JdkFinder will be removed soon (RFR (S): 8015497: Take new fixes from
>> hotspot/test/testlibrary to jdk/test/lib/testlibrary).
>>
>> The example how to use can be found in
>> sun/management/jmxremote/bootstrap/LocalManagementTest.java.
>
> Why not. But I will need to wait till your changes are in ...

Sorry, ProcessBuilder's createJavaProcessBuilder() of course, which in 
turn uses JDKToolLauncher.

If you'll use ProcessBuilder's createJavaProcessBuilder() you don't need 
to wait. Before my fix it will use JdkFinder and after it JDKToolLauncher.

// Katja

>
> -JB-
>
>>
>> Thanks,
>> Katja
>>
>>
>>
>> On 11/07/2013 03:01 PM, Jaroslav Bachorik wrote:
>>> Please, review this test fix.
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8004126
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004126/webrev.00
>>>
>>> The failure was caused by the IOHandler not waiting for the actual
>>> message stating the the debugee was ready. The patch uses the library
>>> functions to start the debugee and wait for the actual message to
>>> appear. Also, it detects problems while starting the debugee and
>>> reports them instead of failing only when the debugger can not connect.
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>


From roger.riggs at oracle.com  Thu Nov  7 13:16:45 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 07 Nov 2013 16:16:45 -0500
Subject: jmx-dev RFR Doclint cleanup of javax.management
Message-ID: <527C033D.1080302@oracle.com>

This changeset addresses the warnings and errors of doclint and
improves the quality of the generated html.
No spec or implementation is changed by this changeset

The changes address issues including html syntax, accessibility issues,
and html tag improper use. Refer to the error log attached to the bug 
report [1] for details.

Please review:
    http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/

Thanks, Roger


[1] https://bugs.openjdk.java.net/browse/JDK-8028014

From roger.riggs at oracle.com  Tue Nov 12 06:52:41 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 12 Nov 2013 09:52:41 -0500
Subject: jmx-dev RFR Doclint cleanup of javax.management
In-Reply-To: <5281F961.9090502@oracle.com>
References: <527C033D.1080302@oracle.com> <52815847.9070304@oracle.com>
	<5281F961.9090502@oracle.com>
Message-ID: <528240B9.1060008@oracle.com>

Hi Jaroslav,

Thanks for the review and comments.

I derived the changes from the warning messages from -Xdoclint.

For both <p> and <li> the closing tag is optional  in HTML 4.01 
Transitional generated by javadoc.
The convention in the core libraries seems to be to omit them,
reducing the amount of [unnecessary] markup in the source.

Did you use a tool to flag these?  Which?

The webrev is updated with the corrections below.
Please me know if you agree or not.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/


On 11/12/2013 4:48 AM, Jaroslav Bachorik wrote:
> Hi Roger,
>
> The following comments are based on the presumption that the contained 
> HTML should be well-formed.
>
> src/share/classes/javax/management/MBeanFeatureInfo.java
> L183, L231 - missing </p>
For these the natural </p> would be at L169, L215; but can be/are omitted.
>
> src/share/classes/javax/management/MBeanInfo.java
> L640, L686 - missing </p>
>
> src/share/classes/javax/management/MBeanServerConnection.java
> L630 - missing </p>
>
> src/share/classes/javax/management/MBeanServerNotification.java
> L89 - missing </p>
>
> src/share/classes/javax/management/MXBean.java
> L788 - missing </p>
>
> src/share/classes/javax/management/ObjectName.java
> L198 - missing </p>
> L204 - missing </p>
> L1552 - missing </p>
>
> src/share/classes/javax/management/PersistentMBean.java
> L78 - missing </p><p>
> L79 - there should be <pre> after this line
> L83 - should be * }</PRE></p>
Corrected to restore the structure.
>
> src/share/classes/javax/management/loading/MLet.java
> L154 - extraneous </dd>
(These lines had improper nesting in the original).
L154 </dd> matches L151 <dd>
L158 </dd> matches L144 <dd>
>
> src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java 
>
> L130 - missing </p>
>
> src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java 
>
> L83 - missing </p>
>
> src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java 
>
> L123 - missing </p>
>
> src/share/classes/javax/management/remote/JMXConnector.java
> L79 - missing </p>
>
> src/share/classes/javax/management/remote/rmi/RMIConnector.java
> L1697 - missing </li> after this line
> L1701 - missing </li> after this line
Added to be consistent with file local conventions.

Thanks, Roger

>
> -JB-
>
> On 11.11.2013 23:20, roger riggs wrote:
>> Please review and comment.
>>
>> This changeset addresses the warnings and errors of doclint and
>> improves the quality of the generated html.
>> No spec or implementation is changed by this changeset
>>
>> The changes address issues including html syntax, accessibility issues,
>> and html tag improper use and list structure.
>> Refer to the error log attached to the bug report [1] for details.
>>
>> Please review:
>>     http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/
>>
>> Thanks, Roger
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8028014
>>
>


From jaroslav.bachorik at oracle.com  Tue Nov 12 07:23:52 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 12 Nov 2013 16:23:52 +0100
Subject: jmx-dev RFR Doclint cleanup of javax.management
In-Reply-To: <528240B9.1060008@oracle.com>
References: <527C033D.1080302@oracle.com>
	<52815847.9070304@oracle.com>	<5281F961.9090502@oracle.com>
	<528240B9.1060008@oracle.com>
Message-ID: <52824808.8050903@oracle.com>

Hi Roger,

On 12.11.2013 15:52, roger riggs wrote:
> Hi Jaroslav,
>
> Thanks for the review and comments.
>
> I derived the changes from the warning messages from -Xdoclint.
>
> For both <p> and <li> the closing tag is optional  in HTML 4.01
> Transitional generated by javadoc.
> The convention in the core libraries seems to be to omit them,
> reducing the amount of [unnecessary] markup in the source.

That's fine. I just wanted to be sure it was intended.

>
> Did you use a tool to flag these?  Which?

Manually :[

>
> The webrev is updated with the corrections below.
> Please me know if you agree or not.

I'm fine with it now. However, I am not an official reviewer.

-JB-

>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/
>
>
> On 11/12/2013 4:48 AM, Jaroslav Bachorik wrote:
>> Hi Roger,
>>
>> The following comments are based on the presumption that the contained
>> HTML should be well-formed.
>>
>> src/share/classes/javax/management/MBeanFeatureInfo.java
>> L183, L231 - missing </p>
> For these the natural </p> would be at L169, L215; but can be/are omitted.
>>
>> src/share/classes/javax/management/MBeanInfo.java
>> L640, L686 - missing </p>
>>
>> src/share/classes/javax/management/MBeanServerConnection.java
>> L630 - missing </p>
>>
>> src/share/classes/javax/management/MBeanServerNotification.java
>> L89 - missing </p>
>>
>> src/share/classes/javax/management/MXBean.java
>> L788 - missing </p>
>>
>> src/share/classes/javax/management/ObjectName.java
>> L198 - missing </p>
>> L204 - missing </p>
>> L1552 - missing </p>
>>
>> src/share/classes/javax/management/PersistentMBean.java
>> L78 - missing </p><p>
>> L79 - there should be <pre> after this line
>> L83 - should be * }</PRE></p>
> Corrected to restore the structure.
>>
>> src/share/classes/javax/management/loading/MLet.java
>> L154 - extraneous </dd>
> (These lines had improper nesting in the original).
> L154 </dd> matches L151 <dd>
> L158 </dd> matches L144 <dd>
>>
>> src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java
>>
>> L130 - missing </p>
>>
>> src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
>>
>> L83 - missing </p>
>>
>> src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java
>>
>> L123 - missing </p>
>>
>> src/share/classes/javax/management/remote/JMXConnector.java
>> L79 - missing </p>
>>
>> src/share/classes/javax/management/remote/rmi/RMIConnector.java
>> L1697 - missing </li> after this line
>> L1701 - missing </li> after this line
> Added to be consistent with file local conventions.
>
> Thanks, Roger
>
>>
>> -JB-
>>
>> On 11.11.2013 23:20, roger riggs wrote:
>>> Please review and comment.
>>>
>>> This changeset addresses the warnings and errors of doclint and
>>> improves the quality of the generated html.
>>> No spec or implementation is changed by this changeset
>>>
>>> The changes address issues including html syntax, accessibility issues,
>>> and html tag improper use and list structure.
>>> Refer to the error log attached to the bug report [1] for details.
>>>
>>> Please review:
>>>     http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/
>>>
>>> Thanks, Roger
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8028014
>>>
>>
>


From staffan.larsen at oracle.com  Tue Nov 12 10:25:23 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 12 Nov 2013 19:25:23 +0100
Subject: jmx-dev RFR Doclint cleanup of javax.management
In-Reply-To: <528240B9.1060008@oracle.com>
References: <527C033D.1080302@oracle.com> <52815847.9070304@oracle.com>
	<5281F961.9090502@oracle.com> <528240B9.1060008@oracle.com>
Message-ID: <111AF42F-7BEC-4271-8B42-8A7FBAF8275A@oracle.com>

Looks good!

Thanks,
/Staffan


On 12 Nov 2013, at 15:52, roger riggs <roger.riggs at oracle.com> wrote:

> Hi Jaroslav,
> 
> Thanks for the review and comments.
> 
> I derived the changes from the warning messages from -Xdoclint.
> 
> For both <p> and <li> the closing tag is optional  in HTML 4.01 Transitional generated by javadoc.
> The convention in the core libraries seems to be to omit them,
> reducing the amount of [unnecessary] markup in the source.
> 
> Did you use a tool to flag these?  Which?
> 
> The webrev is updated with the corrections below.
> Please me know if you agree or not.
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/
> 
> 
> On 11/12/2013 4:48 AM, Jaroslav Bachorik wrote:
>> Hi Roger,
>> 
>> The following comments are based on the presumption that the contained HTML should be well-formed.
>> 
>> src/share/classes/javax/management/MBeanFeatureInfo.java
>> L183, L231 - missing </p>
> For these the natural </p> would be at L169, L215; but can be/are omitted.
>> 
>> src/share/classes/javax/management/MBeanInfo.java
>> L640, L686 - missing </p>
>> 
>> src/share/classes/javax/management/MBeanServerConnection.java
>> L630 - missing </p>
>> 
>> src/share/classes/javax/management/MBeanServerNotification.java
>> L89 - missing </p>
>> 
>> src/share/classes/javax/management/MXBean.java
>> L788 - missing </p>
>> 
>> src/share/classes/javax/management/ObjectName.java
>> L198 - missing </p>
>> L204 - missing </p>
>> L1552 - missing </p>
>> 
>> src/share/classes/javax/management/PersistentMBean.java
>> L78 - missing </p><p>
>> L79 - there should be <pre> after this line
>> L83 - should be * }</PRE></p>
> Corrected to restore the structure.
>> 
>> src/share/classes/javax/management/loading/MLet.java
>> L154 - extraneous </dd>
> (These lines had improper nesting in the original).
> L154 </dd> matches L151 <dd>
> L158 </dd> matches L144 <dd>
>> 
>> src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java 
>> L130 - missing </p>
>> 
>> src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java 
>> L83 - missing </p>
>> 
>> src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java 
>> L123 - missing </p>
>> 
>> src/share/classes/javax/management/remote/JMXConnector.java
>> L79 - missing </p>
>> 
>> src/share/classes/javax/management/remote/rmi/RMIConnector.java
>> L1697 - missing </li> after this line
>> L1701 - missing </li> after this line
> Added to be consistent with file local conventions.
> 
> Thanks, Roger
> 
>> 
>> -JB-
>> 
>> On 11.11.2013 23:20, roger riggs wrote:
>>> Please review and comment.
>>> 
>>> This changeset addresses the warnings and errors of doclint and
>>> improves the quality of the generated html.
>>> No spec or implementation is changed by this changeset
>>> 
>>> The changes address issues including html syntax, accessibility issues,
>>> and html tag improper use and list structure.
>>> Refer to the error log attached to the bug report [1] for details.
>>> 
>>> Please review:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-lint-mgmt-8028014/
>>> 
>>> Thanks, Roger
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8028014

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20131112/c90aadad/attachment.html 

From jaroslav.bachorik at oracle.com  Fri Nov 15 06:25:32 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 15 Nov 2013 15:25:32 +0100
Subject: jmx-dev RFR 8022221: Intermittent test failures in
	sun/management/jmxremote/startstop/JMXStartStopTest.sh
Message-ID: <52862EDC.4080703@oracle.com>

Please, review this test fix.

Issue : https://bugs.openjdk.java.net/browse/JDK-8022221
Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00

The test was facing intermittent failures due to not 100% failproof 
interprocess synchronization using lock files. The solution is rewriting 
the shell test to pure Java and use stdout/stderr processing for the 
application started by the test to assess its status.

A part of the change is also few improvements to the 
jdk.testlibrary.ProcessTools.

Thanks,

-JB-

From jaroslav.bachorik at oracle.com  Mon Nov 18 01:59:17 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 18 Nov 2013 10:59:17 +0100
Subject: jmx-dev RFR 6309226: TEST:
 java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't
 check Thread.sleep
In-Reply-To: <52651646.4050705@oracle.com>
References: <52651646.4050705@oracle.com>
Message-ID: <5289E4F5.1080807@oracle.com>

Hi,

after discussing this with Mandy I've rewritten the test to use the 
j.u.concurrent for synchronization - this also makes it much easier to 
follow the test logic.

The waited time, the blocked time and the waited counts are only checked 
for sanity (increasing values) since it is not possible to do the 
reliable checks against hard numbers.

I ran the test in a tight loop for 1500 times using -Xcomp and -Xint and 
the test seems to pass constantly.

New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03

Thanks,

-JB-


On 21.10.2013 13:55, Jaroslav Bachorik wrote:
> Please, review this small patch for a test failing due to the updated
> implementation in JDK6.
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-6309226
> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/
>
> The test fails due to the change in mustang where
> ThreadMXBean.getThreadInfo().getWaitedTime() and
> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep()
> too. Unfortunately, Thread.sleep() is used throughout the test for
> synchronization purposes and this breaks the test.
>
> In the patch I propose to replace Thread.sleep() with busy wait and
> hinting the scheduler by Thread.yield(). While not very elegant it
> successfully works around inclusion of unknown number of Thread.sleep()s
> (they are called in loop).
>
> Thanks,
>
> -JB-


From jaroslav.bachorik at oracle.com  Mon Nov 18 02:09:24 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 18 Nov 2013 11:09:24 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
 sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be
 updated for jdk8 removal of solaris-32bit support
In-Reply-To: <52779BFE.1080704@oracle.com>
References: <52779BFE.1080704@oracle.com>
Message-ID: <5289E754.7050503@oracle.com>

Could I get this reviewed, please?

-JB-

On 4.11.2013 14:07, Jaroslav Bachorik wrote:
> Please, review the following test change:
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>
> Currently, the test is designed to work only on solaris-32bit. With the
> support removed it is necessary to adapt the test as well. This includes
> generating the solaris-sparcv9 and solaris-amd64 binaries for the
> launcher the test is using.
>
> The test itself needs changing the way it retrieves the ARCH name for
> sparcv9 architecture. Also, since it is forbidden to check in any files
> with executable permissions the test must account for this and adjust
> the file permissions temporarily while executing. It needs to revert to
> the original permissions when it's finished to prevent reporting the
> launcher files as modified in HG.
>
> While testing the changes the
> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
> intermittently (50%) when run in agentvm mode together with
> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
> to run in othervm mode seems to fix the problem.
>
> There is a small debugging improvement in
> ProcessTools.java#startProcess() method - when the phaser timesout or is
> interrupted all the stack traces are dumped to stderr to help diagnosing
> any locking situations.
>
> Thanks,
>
> -JB-


From staffan.larsen at oracle.com  Mon Nov 18 03:50:29 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 18 Nov 2013 12:50:29 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
	sun/management/jmxremote/bootstrap/CustomLauncherTest.java
	should be updated for jdk8 removal of solaris-32bit support
In-Reply-To: <5289E754.7050503@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
Message-ID: <EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>

Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?

/Staffan

On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> Could I get this reviewed, please?
> 
> -JB-
> 
> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>> Please, review the following test change:
>> 
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>> 
>> Currently, the test is designed to work only on solaris-32bit. With the
>> support removed it is necessary to adapt the test as well. This includes
>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>> launcher the test is using.
>> 
>> The test itself needs changing the way it retrieves the ARCH name for
>> sparcv9 architecture. Also, since it is forbidden to check in any files
>> with executable permissions the test must account for this and adjust
>> the file permissions temporarily while executing. It needs to revert to
>> the original permissions when it's finished to prevent reporting the
>> launcher files as modified in HG.
>> 
>> While testing the changes the
>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>> intermittently (50%) when run in agentvm mode together with
>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>> to run in othervm mode seems to fix the problem.
>> 
>> There is a small debugging improvement in
>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>> interrupted all the stack traces are dumped to stderr to help diagnosing
>> any locking situations.
>> 
>> Thanks,
>> 
>> -JB-
> 


From jaroslav.bachorik at oracle.com  Mon Nov 18 04:00:28 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 18 Nov 2013 13:00:28 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
 sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be
 updated for jdk8 removal of solaris-32bit support
In-Reply-To: <EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
Message-ID: <528A015C.20706@oracle.com>

On 18.11.2013 12:50, Staffan Larsen wrote:
> Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?

Probably yes - if there are no 32bit solaris build hosts then it can be 
removed.

-JB-

>
> /Staffan
>
> On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>
>> Could I get this reviewed, please?
>>
>> -JB-
>>
>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>> Please, review the following test change:
>>>
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>
>>> Currently, the test is designed to work only on solaris-32bit. With the
>>> support removed it is necessary to adapt the test as well. This includes
>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>> launcher the test is using.
>>>
>>> The test itself needs changing the way it retrieves the ARCH name for
>>> sparcv9 architecture. Also, since it is forbidden to check in any files
>>> with executable permissions the test must account for this and adjust
>>> the file permissions temporarily while executing. It needs to revert to
>>> the original permissions when it's finished to prevent reporting the
>>> launcher files as modified in HG.
>>>
>>> While testing the changes the
>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>>> intermittently (50%) when run in agentvm mode together with
>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>>> to run in othervm mode seems to fix the problem.
>>>
>>> There is a small debugging improvement in
>>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>>> interrupted all the stack traces are dumped to stderr to help diagnosing
>>> any locking situations.
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>


From staffan.larsen at oracle.com  Mon Nov 18 04:06:39 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 18 Nov 2013 13:06:39 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
	sun/management/jmxremote/bootstrap/CustomLauncherTest.java
	should be updated for jdk8 removal of solaris-32bit support
In-Reply-To: <528A015C.20706@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
	<528A015C.20706@oracle.com>
Message-ID: <17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>

We don?t have solaris 32bit support any more, so please remove that file.

Otherwise: looks good!

/Staffan

On 18 Nov 2013, at 13:00, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> On 18.11.2013 12:50, Staffan Larsen wrote:
>> Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?
> 
> Probably yes - if there are no 32bit solaris build hosts then it can be removed.
> 
> -JB-
> 
>> 
>> /Staffan
>> 
>> On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>> 
>>> Could I get this reviewed, please?
>>> 
>>> -JB-
>>> 
>>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>>> Please, review the following test change:
>>>> 
>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>> 
>>>> Currently, the test is designed to work only on solaris-32bit. With the
>>>> support removed it is necessary to adapt the test as well. This includes
>>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>>> launcher the test is using.
>>>> 
>>>> The test itself needs changing the way it retrieves the ARCH name for
>>>> sparcv9 architecture. Also, since it is forbidden to check in any files
>>>> with executable permissions the test must account for this and adjust
>>>> the file permissions temporarily while executing. It needs to revert to
>>>> the original permissions when it's finished to prevent reporting the
>>>> launcher files as modified in HG.
>>>> 
>>>> While testing the changes the
>>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>>>> intermittently (50%) when run in agentvm mode together with
>>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>>>> to run in othervm mode seems to fix the problem.
>>>> 
>>>> There is a small debugging improvement in
>>>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>>>> interrupted all the stack traces are dumped to stderr to help diagnosing
>>>> any locking situations.
>>>> 
>>>> Thanks,
>>>> 
>>>> -JB-
>>> 
>> 
> 


From jaroslav.bachorik at oracle.com  Mon Nov 18 04:15:51 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 18 Nov 2013 13:15:51 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
 sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be
 updated for jdk8 removal of solaris-32bit support
In-Reply-To: <17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
	<528A015C.20706@oracle.com>
	<17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>
Message-ID: <528A04F7.9090605@oracle.com>

On 18.11.2013 13:06, Staffan Larsen wrote:
> We don?t have solaris 32bit support any more, so please remove that file.

In that case I will remove also solaris-i586

-JB-

>
> Otherwise: looks good!
>
> /Staffan
>
> On 18 Nov 2013, at 13:00, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>
>> On 18.11.2013 12:50, Staffan Larsen wrote:
>>> Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?
>>
>> Probably yes - if there are no 32bit solaris build hosts then it can be removed.
>>
>> -JB-
>>
>>>
>>> /Staffan
>>>
>>> On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>>>
>>>> Could I get this reviewed, please?
>>>>
>>>> -JB-
>>>>
>>>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>>>> Please, review the following test change:
>>>>>
>>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>>>
>>>>> Currently, the test is designed to work only on solaris-32bit. With the
>>>>> support removed it is necessary to adapt the test as well. This includes
>>>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>>>> launcher the test is using.
>>>>>
>>>>> The test itself needs changing the way it retrieves the ARCH name for
>>>>> sparcv9 architecture. Also, since it is forbidden to check in any files
>>>>> with executable permissions the test must account for this and adjust
>>>>> the file permissions temporarily while executing. It needs to revert to
>>>>> the original permissions when it's finished to prevent reporting the
>>>>> launcher files as modified in HG.
>>>>>
>>>>> While testing the changes the
>>>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>>>>> intermittently (50%) when run in agentvm mode together with
>>>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>>>>> to run in othervm mode seems to fix the problem.
>>>>>
>>>>> There is a small debugging improvement in
>>>>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>>>>> interrupted all the stack traces are dumped to stderr to help diagnosing
>>>>> any locking situations.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -JB-
>>>>
>>>
>>
>


From staffan.larsen at oracle.com  Mon Nov 18 04:51:39 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 18 Nov 2013 13:51:39 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
	sun/management/jmxremote/bootstrap/CustomLauncherTest.java
	should be updated for jdk8 removal of solaris-32bit support
In-Reply-To: <528A04F7.9090605@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
	<528A015C.20706@oracle.com>
	<17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>
	<528A04F7.9090605@oracle.com>
Message-ID: <A0617182-49B0-48EA-A9FA-1FD1DF96592A@oracle.com>

Ah! Yes.

/S

On 18 Nov 2013, at 13:15, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> On 18.11.2013 13:06, Staffan Larsen wrote:
>> We don?t have solaris 32bit support any more, so please remove that file.
> 
> In that case I will remove also solaris-i586
> 
> -JB-
> 
>> 
>> Otherwise: looks good!
>> 
>> /Staffan
>> 
>> On 18 Nov 2013, at 13:00, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>> 
>>> On 18.11.2013 12:50, Staffan Larsen wrote:
>>>> Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?
>>> 
>>> Probably yes - if there are no 32bit solaris build hosts then it can be removed.
>>> 
>>> -JB-
>>> 
>>>> 
>>>> /Staffan
>>>> 
>>>> On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>>>> 
>>>>> Could I get this reviewed, please?
>>>>> 
>>>>> -JB-
>>>>> 
>>>>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>>>>> Please, review the following test change:
>>>>>> 
>>>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>>>> 
>>>>>> Currently, the test is designed to work only on solaris-32bit. With the
>>>>>> support removed it is necessary to adapt the test as well. This includes
>>>>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>>>>> launcher the test is using.
>>>>>> 
>>>>>> The test itself needs changing the way it retrieves the ARCH name for
>>>>>> sparcv9 architecture. Also, since it is forbidden to check in any files
>>>>>> with executable permissions the test must account for this and adjust
>>>>>> the file permissions temporarily while executing. It needs to revert to
>>>>>> the original permissions when it's finished to prevent reporting the
>>>>>> launcher files as modified in HG.
>>>>>> 
>>>>>> While testing the changes the
>>>>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>>>>>> intermittently (50%) when run in agentvm mode together with
>>>>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>>>>>> to run in othervm mode seems to fix the problem.
>>>>>> 
>>>>>> There is a small debugging improvement in
>>>>>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>>>>>> interrupted all the stack traces are dumped to stderr to help diagnosing
>>>>>> any locking situations.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> -JB-
>>>>> 
>>>> 
>>> 
>> 
> 


From jaroslav.bachorik at oracle.com  Mon Nov 18 05:41:29 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 18 Nov 2013 14:41:29 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
 sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be
 updated for jdk8 removal of solaris-32bit support
In-Reply-To: <A0617182-49B0-48EA-A9FA-1FD1DF96592A@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
	<528A015C.20706@oracle.com>
	<17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>
	<528A04F7.9090605@oracle.com>
	<A0617182-49B0-48EA-A9FA-1FD1DF96592A@oracle.com>
Message-ID: <528A1909.1050106@oracle.com>

Ok, just to be sure - 
http://cr.openjdk.java.net/~jbachorik/8027163/webrev.01

-JB-

On 18.11.2013 13:51, Staffan Larsen wrote:
> Ah! Yes.
>
> /S
>
> On 18 Nov 2013, at 13:15, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>
>> On 18.11.2013 13:06, Staffan Larsen wrote:
>>> We don?t have solaris 32bit support any more, so please remove that file.
>>
>> In that case I will remove also solaris-i586
>>
>> -JB-
>>
>>>
>>> Otherwise: looks good!
>>>
>>> /Staffan
>>>
>>> On 18 Nov 2013, at 13:00, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>>>
>>>> On 18.11.2013 12:50, Staffan Larsen wrote:
>>>>> Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?
>>>>
>>>> Probably yes - if there are no 32bit solaris build hosts then it can be removed.
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>> On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>>>>>
>>>>>> Could I get this reviewed, please?
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>>>>>> Please, review the following test change:
>>>>>>>
>>>>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>>>>>
>>>>>>> Currently, the test is designed to work only on solaris-32bit. With the
>>>>>>> support removed it is necessary to adapt the test as well. This includes
>>>>>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>>>>>> launcher the test is using.
>>>>>>>
>>>>>>> The test itself needs changing the way it retrieves the ARCH name for
>>>>>>> sparcv9 architecture. Also, since it is forbidden to check in any files
>>>>>>> with executable permissions the test must account for this and adjust
>>>>>>> the file permissions temporarily while executing. It needs to revert to
>>>>>>> the original permissions when it's finished to prevent reporting the
>>>>>>> launcher files as modified in HG.
>>>>>>>
>>>>>>> While testing the changes the
>>>>>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>>>>>>> intermittently (50%) when run in agentvm mode together with
>>>>>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>>>>>>> to run in othervm mode seems to fix the problem.
>>>>>>>
>>>>>>> There is a small debugging improvement in
>>>>>>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>>>>>>> interrupted all the stack traces are dumped to stderr to help diagnosing
>>>>>>> any locking situations.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -JB-
>>>>>>
>>>>>
>>>>
>>>
>>
>


From staffan.larsen at oracle.com  Mon Nov 18 06:09:21 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 18 Nov 2013 15:09:21 +0100
Subject: jmx-dev [ping] Re: RFR 8027163:
	sun/management/jmxremote/bootstrap/CustomLauncherTest.java
	should be updated for jdk8 removal of solaris-32bit support
In-Reply-To: <528A1909.1050106@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
	<528A015C.20706@oracle.com>
	<17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>
	<528A04F7.9090605@oracle.com>
	<A0617182-49B0-48EA-A9FA-1FD1DF96592A@oracle.com>
	<528A1909.1050106@oracle.com>
Message-ID: <38B51663-5BAF-4FE0-B7D4-715576C69E24@oracle.com>

Reviewed.

/Staffan

On 18 Nov 2013, at 14:41, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> Ok, just to be sure - http://cr.openjdk.java.net/~jbachorik/8027163/webrev.01
> 
> -JB-
> 
> On 18.11.2013 13:51, Staffan Larsen wrote:
>> Ah! Yes.
>> 
>> /S
>> 
>> On 18 Nov 2013, at 13:15, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>> 
>>> On 18.11.2013 13:06, Staffan Larsen wrote:
>>>> We don?t have solaris 32bit support any more, so please remove that file.
>>> 
>>> In that case I will remove also solaris-i586
>>> 
>>> -JB-
>>> 
>>>> 
>>>> Otherwise: looks good!
>>>> 
>>>> /Staffan
>>>> 
>>>> On 18 Nov 2013, at 13:00, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>>>> 
>>>>> On 18.11.2013 12:50, Staffan Larsen wrote:
>>>>>> Shouldn?t test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be removed as part of this change?
>>>>> 
>>>>> Probably yes - if there are no 32bit solaris build hosts then it can be removed.
>>>>> 
>>>>> -JB-
>>>>> 
>>>>>> 
>>>>>> /Staffan
>>>>>> 
>>>>>> On 18 Nov 2013, at 11:09, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
>>>>>> 
>>>>>>> Could I get this reviewed, please?
>>>>>>> 
>>>>>>> -JB-
>>>>>>> 
>>>>>>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>>>>>>> Please, review the following test change:
>>>>>>>> 
>>>>>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>>>>>> 
>>>>>>>> Currently, the test is designed to work only on solaris-32bit. With the
>>>>>>>> support removed it is necessary to adapt the test as well. This includes
>>>>>>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>>>>>>> launcher the test is using.
>>>>>>>> 
>>>>>>>> The test itself needs changing the way it retrieves the ARCH name for
>>>>>>>> sparcv9 architecture. Also, since it is forbidden to check in any files
>>>>>>>> with executable permissions the test must account for this and adjust
>>>>>>>> the file permissions temporarily while executing. It needs to revert to
>>>>>>>> the original permissions when it's finished to prevent reporting the
>>>>>>>> launcher files as modified in HG.
>>>>>>>> 
>>>>>>>> While testing the changes the
>>>>>>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept failing
>>>>>>>> intermittently (50%) when run in agentvm mode together with
>>>>>>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of these tests
>>>>>>>> to run in othervm mode seems to fix the problem.
>>>>>>>> 
>>>>>>>> There is a small debugging improvement in
>>>>>>>> ProcessTools.java#startProcess() method - when the phaser timesout or is
>>>>>>>> interrupted all the stack traces are dumped to stderr to help diagnosing
>>>>>>>> any locking situations.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> -JB-
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From david.holmes at oracle.com  Mon Nov 18 12:43:20 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Nov 2013 06:43:20 +1000
Subject: jmx-dev [ping] Re: RFR 8027163:
 sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be
 updated for jdk8 removal of solaris-32bit support
In-Reply-To: <528A1909.1050106@oracle.com>
References: <52779BFE.1080704@oracle.com> <5289E754.7050503@oracle.com>
	<EC2776E8-709F-42E2-9B50-91A860E034B6@oracle.com>
	<528A015C.20706@oracle.com>
	<17C44C25-C9D0-477A-A673-8306B608483C@oracle.com>
	<528A04F7.9090605@oracle.com>
	<A0617182-49B0-48EA-A9FA-1FD1DF96592A@oracle.com>
	<528A1909.1050106@oracle.com>
Message-ID: <528A7BE8.5010400@oracle.com>

On 18/11/2013 11:41 PM, Jaroslav Bachorik wrote:
> Ok, just to be sure -
> http://cr.openjdk.java.net/~jbachorik/8027163/webrev.01

Minor nits ...

Missing space after for( in

test/lib/testlibrary/jdk/testlibrary/ProcessTools.java

+             for(Map.Entry<Thread, StackTraceElement[]> s

BTW you should be able to simply to:

+             for(Map.Entry<> s

---

test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java

Need space around &&

Cheers,
David
------

> -JB-
>
> On 18.11.2013 13:51, Staffan Larsen wrote:
>> Ah! Yes.
>>
>> /S
>>
>> On 18 Nov 2013, at 13:15, Jaroslav Bachorik
>> <jaroslav.bachorik at oracle.com> wrote:
>>
>>> On 18.11.2013 13:06, Staffan Larsen wrote:
>>>> We don?t have solaris 32bit support any more, so please remove that
>>>> file.
>>>
>>> In that case I will remove also solaris-i586
>>>
>>> -JB-
>>>
>>>>
>>>> Otherwise: looks good!
>>>>
>>>> /Staffan
>>>>
>>>> On 18 Nov 2013, at 13:00, Jaroslav Bachorik
>>>> <jaroslav.bachorik at oracle.com> wrote:
>>>>
>>>>> On 18.11.2013 12:50, Staffan Larsen wrote:
>>>>>> Shouldn?t
>>>>>> test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher be
>>>>>> removed as part of this change?
>>>>>
>>>>> Probably yes - if there are no 32bit solaris build hosts then it
>>>>> can be removed.
>>>>>
>>>>> -JB-
>>>>>
>>>>>>
>>>>>> /Staffan
>>>>>>
>>>>>> On 18 Nov 2013, at 11:09, Jaroslav Bachorik
>>>>>> <jaroslav.bachorik at oracle.com> wrote:
>>>>>>
>>>>>>> Could I get this reviewed, please?
>>>>>>>
>>>>>>> -JB-
>>>>>>>
>>>>>>> On 4.11.2013 14:07, Jaroslav Bachorik wrote:
>>>>>>>> Please, review the following test change:
>>>>>>>>
>>>>>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8027163
>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027163/webrev.00/
>>>>>>>>
>>>>>>>> Currently, the test is designed to work only on solaris-32bit.
>>>>>>>> With the
>>>>>>>> support removed it is necessary to adapt the test as well. This
>>>>>>>> includes
>>>>>>>> generating the solaris-sparcv9 and solaris-amd64 binaries for the
>>>>>>>> launcher the test is using.
>>>>>>>>
>>>>>>>> The test itself needs changing the way it retrieves the ARCH
>>>>>>>> name for
>>>>>>>> sparcv9 architecture. Also, since it is forbidden to check in
>>>>>>>> any files
>>>>>>>> with executable permissions the test must account for this and
>>>>>>>> adjust
>>>>>>>> the file permissions temporarily while executing. It needs to
>>>>>>>> revert to
>>>>>>>> the original permissions when it's finished to prevent reporting
>>>>>>>> the
>>>>>>>> launcher files as modified in HG.
>>>>>>>>
>>>>>>>> While testing the changes the
>>>>>>>> sun/management/jmxremote/bootstrap/LocalManagementTest.java kept
>>>>>>>> failing
>>>>>>>> intermittently (50%) when run in agentvm mode together with
>>>>>>>> CustomLauncherTest.java on sparcv9 machines. Forcing both of
>>>>>>>> these tests
>>>>>>>> to run in othervm mode seems to fix the problem.
>>>>>>>>
>>>>>>>> There is a small debugging improvement in
>>>>>>>> ProcessTools.java#startProcess() method - when the phaser
>>>>>>>> timesout or is
>>>>>>>> interrupted all the stack traces are dumped to stderr to help
>>>>>>>> diagnosing
>>>>>>>> any locking situations.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -JB-
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From david.holmes at oracle.com  Mon Nov 18 13:03:00 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Nov 2013 07:03:00 +1000
Subject: jmx-dev RFR 6309226: TEST:
 java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't
 check Thread.sleep
In-Reply-To: <5289E4F5.1080807@oracle.com>
References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com>
Message-ID: <528A8084.5060406@oracle.com>

Hi Jaroslav,

I think your phaser usage is incorrect:

  88             public void run() {
   89                 p.arriveAndAwaitAdvance(); // phase[1]
   90                 synchronized(lock1) {
   91                     System.out.println("[LockerThread obtained 
Lock1]");
   92                     p.arrive(); // phase[2]
   93                 }
   94                 p.arriveAndAwaitAdvance(); // phase[3]
   95             }

Here the current thread can release itself at line 94. You have assumed 
that the phase[2] arrive will be a trigger to release the main thread 
but it may not have reached its arriveAndAwaitAdvance phase[2] statement 
yet, so the current thread arrives then does arrive-and-wait but the 
number of arrivals is 2 so it doesn't wait.

A CyclicBarrier per phase may be clearer.

David

On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote:
> Hi,
>
> after discussing this with Mandy I've rewritten the test to use the
> j.u.concurrent for synchronization - this also makes it much easier to
> follow the test logic.
>
> The waited time, the blocked time and the waited counts are only checked
> for sanity (increasing values) since it is not possible to do the
> reliable checks against hard numbers.
>
> I ran the test in a tight loop for 1500 times using -Xcomp and -Xint and
> the test seems to pass constantly.
>
> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03
>
> Thanks,
>
> -JB-
>
>
> On 21.10.2013 13:55, Jaroslav Bachorik wrote:
>> Please, review this small patch for a test failing due to the updated
>> implementation in JDK6.
>>
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-6309226
>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/
>>
>> The test fails due to the change in mustang where
>> ThreadMXBean.getThreadInfo().getWaitedTime() and
>> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep()
>> too. Unfortunately, Thread.sleep() is used throughout the test for
>> synchronization purposes and this breaks the test.
>>
>> In the patch I propose to replace Thread.sleep() with busy wait and
>> hinting the scheduler by Thread.yield(). While not very elegant it
>> successfully works around inclusion of unknown number of Thread.sleep()s
>> (they are called in loop).
>>
>> Thanks,
>>
>> -JB-
>

From mandy.chung at oracle.com  Mon Nov 18 14:44:13 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 18 Nov 2013 14:44:13 -0800
Subject: jmx-dev RFR 6309226: TEST:
 java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't
 check Thread.sleep
In-Reply-To: <528A8084.5060406@oracle.com>
References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com>
	<528A8084.5060406@oracle.com>
Message-ID: <528A983D.7080804@oracle.com>

Hi Jaroslav,

This is a good cleanup to make the test more reliable.  Thanks for doing 
that.  I agree with David that it could be possible for the current 
thread to arrive at the phaser two times at the same phase while the 
test expects both threads move to the next step when both arrive.  
CyclicBarrier per phase is a good suggestion.

Nits: testBlocked() has some debugging code that can be removed. It'd be 
good to add more comments to describe the individual test case.

thanks
Mandy

On 11/18/2013 1:03 PM, David Holmes wrote:
> Hi Jaroslav,
>
> I think your phaser usage is incorrect:
>
>  88             public void run() {
>   89                 p.arriveAndAwaitAdvance(); // phase[1]
>   90                 synchronized(lock1) {
>   91                     System.out.println("[LockerThread obtained 
> Lock1]");
>   92                     p.arrive(); // phase[2]
>   93                 }
>   94                 p.arriveAndAwaitAdvance(); // phase[3]
>   95             }
>
> Here the current thread can release itself at line 94. You have 
> assumed that the phase[2] arrive will be a trigger to release the main 
> thread but it may not have reached its arriveAndAwaitAdvance phase[2] 
> statement yet, so the current thread arrives then does arrive-and-wait 
> but the number of arrivals is 2 so it doesn't wait.
>
> A CyclicBarrier per phase may be clearer.
>
> David
>
> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote:
>> Hi,
>>
>> after discussing this with Mandy I've rewritten the test to use the
>> j.u.concurrent for synchronization - this also makes it much easier to
>> follow the test logic.
>>
>> The waited time, the blocked time and the waited counts are only checked
>> for sanity (increasing values) since it is not possible to do the
>> reliable checks against hard numbers.
>>
>> I ran the test in a tight loop for 1500 times using -Xcomp and -Xint and
>> the test seems to pass constantly.
>>
>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03
>>
>> Thanks,
>>
>> -JB-
>>
>>
>> On 21.10.2013 13:55, Jaroslav Bachorik wrote:
>>> Please, review this small patch for a test failing due to the updated
>>> implementation in JDK6.
>>>
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-6309226
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/
>>>
>>> The test fails due to the change in mustang where
>>> ThreadMXBean.getThreadInfo().getWaitedTime() and
>>> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep()
>>> too. Unfortunately, Thread.sleep() is used throughout the test for
>>> synchronization purposes and this breaks the test.
>>>
>>> In the patch I propose to replace Thread.sleep() with busy wait and
>>> hinting the scheduler by Thread.yield(). While not very elegant it
>>> successfully works around inclusion of unknown number of 
>>> Thread.sleep()s
>>> (they are called in loop).
>>>
>>> Thanks,
>>>
>>> -JB-
>>


From jaroslav.bachorik at oracle.com  Tue Nov 19 06:43:18 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 19 Nov 2013 15:43:18 +0100
Subject: jmx-dev RFR 6309226: TEST:
 java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't
 check Thread.sleep
In-Reply-To: <528A8084.5060406@oracle.com>
References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com>
	<528A8084.5060406@oracle.com>
Message-ID: <528B7906.7010708@oracle.com>

Hi David,

On 18.11.2013 22:03, David Holmes wrote:
> Hi Jaroslav,
>
> I think your phaser usage is incorrect:
>
>   88             public void run() {
>    89                 p.arriveAndAwaitAdvance(); // phase[1]
>    90                 synchronized(lock1) {
>    91                     System.out.println("[LockerThread obtained
> Lock1]");
>    92                     p.arrive(); // phase[2]
>    93                 }
>    94                 p.arriveAndAwaitAdvance(); // phase[3]
>    95             }
>
> Here the current thread can release itself at line 94. You have assumed
> that the phase[2] arrive will be a trigger to release the main thread
> but it may not have reached its arriveAndAwaitAdvance phase[2] statement
> yet, so the current thread arrives then does arrive-and-wait but the
> number of arrivals is 2 so it doesn't wait.
>
> A CyclicBarrier per phase may be clearer.

Yes, thanks for pointing this out. But, wouldn't 
p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've tried to 
replace Phaser with CyclicBarrier but while it seems to work as expected 
it pollutes code with the necessity to catch various exceptions 
(InterruptedException, BarrierException etc.). So, if the simple fix 
with Phaser would do the trick I would better use that.

-JB-

>
> David
>
> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote:
>> Hi,
>>
>> after discussing this with Mandy I've rewritten the test to use the
>> j.u.concurrent for synchronization - this also makes it much easier to
>> follow the test logic.
>>
>> The waited time, the blocked time and the waited counts are only checked
>> for sanity (increasing values) since it is not possible to do the
>> reliable checks against hard numbers.
>>
>> I ran the test in a tight loop for 1500 times using -Xcomp and -Xint and
>> the test seems to pass constantly.
>>
>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03
>>
>> Thanks,
>>
>> -JB-
>>
>>
>> On 21.10.2013 13:55, Jaroslav Bachorik wrote:
>>> Please, review this small patch for a test failing due to the updated
>>> implementation in JDK6.
>>>
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-6309226
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/
>>>
>>> The test fails due to the change in mustang where
>>> ThreadMXBean.getThreadInfo().getWaitedTime() and
>>> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep()
>>> too. Unfortunately, Thread.sleep() is used throughout the test for
>>> synchronization purposes and this breaks the test.
>>>
>>> In the patch I propose to replace Thread.sleep() with busy wait and
>>> hinting the scheduler by Thread.yield(). While not very elegant it
>>> successfully works around inclusion of unknown number of Thread.sleep()s
>>> (they are called in loop).
>>>
>>> Thanks,
>>>
>>> -JB-
>>


From david.holmes at oracle.com  Tue Nov 19 10:55:22 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Nov 2013 04:55:22 +1000
Subject: jmx-dev RFR 6309226: TEST:
 java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't
 check Thread.sleep
In-Reply-To: <528B7906.7010708@oracle.com>
References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com>
	<528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com>
Message-ID: <528BB41A.4070107@oracle.com>

On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote:
> Hi David,
>
> On 18.11.2013 22:03, David Holmes wrote:
>> Hi Jaroslav,
>>
>> I think your phaser usage is incorrect:
>>
>>   88             public void run() {
>>    89                 p.arriveAndAwaitAdvance(); // phase[1]
>>    90                 synchronized(lock1) {
>>    91                     System.out.println("[LockerThread obtained
>> Lock1]");
>>    92                     p.arrive(); // phase[2]
>>    93                 }
>>    94                 p.arriveAndAwaitAdvance(); // phase[3]
>>    95             }
>>
>> Here the current thread can release itself at line 94. You have assumed
>> that the phase[2] arrive will be a trigger to release the main thread
>> but it may not have reached its arriveAndAwaitAdvance phase[2] statement
>> yet, so the current thread arrives then does arrive-and-wait but the
>> number of arrivals is 2 so it doesn't wait.
>>
>> A CyclicBarrier per phase may be clearer.
>
> Yes, thanks for pointing this out. But, wouldn't
> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've tried to
> replace Phaser with CyclicBarrier but while it seems to work as expected
> it pollutes code with the necessity to catch various exceptions
> (InterruptedException, BarrierException etc.). So, if the simple fix
> with Phaser would do the trick I would better use that.

In this case yes arriveAndAwaitAdvance would fix it. I don't know if 
other tests have the same issue - the concern would be ensuring there's 
no possibility of deadlocks in general.

Thanks,
David

> -JB-
>
>>
>> David
>>
>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote:
>>> Hi,
>>>
>>> after discussing this with Mandy I've rewritten the test to use the
>>> j.u.concurrent for synchronization - this also makes it much easier to
>>> follow the test logic.
>>>
>>> The waited time, the blocked time and the waited counts are only checked
>>> for sanity (increasing values) since it is not possible to do the
>>> reliable checks against hard numbers.
>>>
>>> I ran the test in a tight loop for 1500 times using -Xcomp and -Xint and
>>> the test seems to pass constantly.
>>>
>>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03
>>>
>>> Thanks,
>>>
>>> -JB-
>>>
>>>
>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote:
>>>> Please, review this small patch for a test failing due to the updated
>>>> implementation in JDK6.
>>>>
>>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-6309226
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/
>>>>
>>>> The test fails due to the change in mustang where
>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and
>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep()
>>>> too. Unfortunately, Thread.sleep() is used throughout the test for
>>>> synchronization purposes and this breaks the test.
>>>>
>>>> In the patch I propose to replace Thread.sleep() with busy wait and
>>>> hinting the scheduler by Thread.yield(). While not very elegant it
>>>> successfully works around inclusion of unknown number of
>>>> Thread.sleep()s
>>>> (they are called in loop).
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>

From shanliang.jiang at oracle.com  Wed Nov 27 07:41:39 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 27 Nov 2013 16:41:39 +0100
Subject: jmx-dev Codereview request: 8029063
 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK
 builds
Message-ID: <529612B3.4000904@oracle.com>

This is a simple test fix,  have to remove the test in OpenJDK because 
the SNMP classes in the OpenJDK will not be compiled if the closed part 
is not present.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff8029063-open
Type: video/x-flv
Size: 5049 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20131127/3cdd0fcb/diff8029063-open.bin 

From Alan.Bateman at oracle.com  Wed Nov 27 07:52:10 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 27 Nov 2013 15:52:10 +0000
Subject: jmx-dev Codereview request: 8029063
 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK
 builds
In-Reply-To: <529612B3.4000904@oracle.com>
References: <529612B3.4000904@oracle.com>
Message-ID: <5296152A.4050202@oracle.com>

On 27/11/2013 15:41, shanliang wrote:
> This is a simple test fix,  have to remove the test in OpenJDK because 
> the SNMP classes in the OpenJDK will not be compiled if the closed 
> part is not present.
Deleting it make sense, thumbs up from me.

-Alan.

From daniel.fuchs at oracle.com  Wed Nov 27 07:55:01 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 27 Nov 2013 16:55:01 +0100
Subject: jmx-dev Codereview request: 8029063
 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK
 builds
In-Reply-To: <529612B3.4000904@oracle.com>
References: <529612B3.4000904@oracle.com>
Message-ID: <529615D5.60806@oracle.com>

On 11/27/13 4:41 PM, shanliang wrote:
> This is a simple test fix,  have to remove the test in OpenJDK because
> the SNMP classes in the OpenJDK will not be compiled if the closed part
> is not present.

looks good.

-- daniel