jmx-dev [ping] Re: RFR 8027163: sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be updated for jdk8 removal of solaris-32bit support

[Jaroslav Bachorik]

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