Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

2014-01-17 Thread Alan Bateman

On 15/01/2014 16:42, Volker Simonis wrote:

Hi Alan,

thanks for the suggestion. That's fine for me. I've copied the empty 
SCTP stubs from the macosx to the aix directory as well and updated 
the make file accordingly (in the patch for 8031581: PPC64: Addons 
and fixes for AIX to pass the jdk regression tests).


Therefore, the changes to the three tests:

test/com/sun/nio/sctp/SctpChannel/Util.java
test/com/sun/nio/sctp/SctpMultiChannel/Util.java
test/com/sun/nio/sctp/SctpServerChannel/Util.java

can be considered obsolete.

Thanks, I think this makes the most sense.

I looked through the rest of this webrev and the update to the tests 
looks fine.


One general comment is that for many of these shell tests (that survive 
the current effort to replace them) is that we could move the Unix 
handling into the match any case so that we don't have to list each of 
Linux, SunOS, Darwin, ...   I think this came up when the OS X port was 
brought in but there wasn't any follow-up on it. I am not suggesting you 
do this here, it's just a comment as I see same change to so many tests.


A minor comment on SBC.java is that it could just catch 
UnsupportedOperationException on L238, that would avoid needing to check 
os.name.


A really minor comment on the updates to ProblemList.txt is that the JMX 
test should probably be in the jdk_jmx section (it's just a convention 
that we've been using, it doesn't of course really matter where tests 
are listed).


-Alan


Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

2014-01-17 Thread Alan Bateman

On 14/01/2014 16:57, Volker Simonis wrote:

Hi,

could you please review the following change:

http://cr.openjdk.java.net/~simonis/webrevs/8028537/

which, together with the changes from 8031581: PPC64: Addons and fixes for
AIX to pass the jdk regression tests and 8031134 : PPC64: implement
printing on AIX enables our our port to pass all but the following 7 jtreg
regression tests on AIX (compared to the Linux/x86_64 baseline from
www.java.net/download/jdk8/testresults/testresults.html‎):

I've finally got to this one. As the event translation issue is now a 
separate issue then I've ignored that part.


I'm not comfortable with the changes to FileDispatcherImpl.c as I don't 
think we shouldn't be calling into IO_ or NET_* functions here. I think 
I get the issue that you have on AIX (and assume it's the preClose/dup2 
that blocks rather than close) but need a bit of time to suggest 
alternatives. It may be that it will require an AIX specific 
SocketDispatcher. Do you happen to know which tests fail due to this part?


The other changes look okay. There is a typo in the change to 
zip_util.c, s/legel/legal/.


In DatagramChannelImpl.c then you handle connect failing with 
EAFNOSUPPORT. I would be tempted to replace the comment to say that it 
EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation 
for rv = errno can be fixed (I see the BSD code has it wrong too).


-Alan.




Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

2014-01-17 Thread Volker Simonis
Hi Alan,

thanks for looking at this. Please find may comments inline:

On Fri, Jan 17, 2014 at 10:48 AM, Alan Bateman alan.bate...@oracle.com wrote:
 On 15/01/2014 16:42, Volker Simonis wrote:

 Hi Alan,

 thanks for the suggestion. That's fine for me. I've copied the empty SCTP
 stubs from the macosx to the aix directory as well and updated the make file
 accordingly (in the patch for 8031581: PPC64: Addons and fixes for AIX to
 pass the jdk regression tests).

 Therefore, the changes to the three tests:

 test/com/sun/nio/sctp/SctpChannel/Util.java
 test/com/sun/nio/sctp/SctpMultiChannel/Util.java
 test/com/sun/nio/sctp/SctpServerChannel/Util.java

 can be considered obsolete.

 Thanks, I think this makes the most sense.

 I looked through the rest of this webrev and the update to the tests looks
 fine.


Great, thanks.

 One general comment is that for many of these shell tests (that survive the
 current effort to replace them) is that we could move the Unix handling into
 the match any case so that we don't have to list each of Linux, SunOS,
 Darwin, ...   I think this came up when the OS X port was brought in but
 there wasn't any follow-up on it. I am not suggesting you do this here, it's
 just a comment as I see same change to so many tests.

 A minor comment on SBC.java is that it could just catch
 UnsupportedOperationException on L238, that would avoid needing to check
 os.name.


I agree, that looks much nicer. Done as requested.

 A really minor comment on the updates to ProblemList.txt is that the JMX
 test should probably be in the jdk_jmx section (it's just a convention that
 we've been using, it doesn't of course really matter where tests are
 listed).

Done. Moved the excluded tests down to the jdk_jmx section.

Here's the new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/8028537_2/

Can I push this now to ppc-aix-port/stage-9?

Thank you and best regards,
Volker


 -Alan


Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

2014-01-17 Thread Alan Bateman

On 17/01/2014 21:10, Volker Simonis wrote:

:
Done. Moved the excluded tests down to the jdk_jmx section.

Here's the new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/8028537_2/

Can I push this now to ppc-aix-port/stage-9?

The SBC change looks good. I can't see the move of the excluded test but 
it's not important anyway.


So I think this one is good to go.

-Alan.


Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

2014-01-15 Thread Volker Simonis
Hi Alan,

thanks for the suggestion. That's fine for me. I've copied the empty SCTP
stubs from the macosx to the aix directory as well and updated the make
file accordingly (in the patch for 8031581: PPC64: Addons and fixes for
AIX to pass the jdk regression tests).

Therefore, the changes to the three tests:

test/com/sun/nio/sctp/SctpChannel/Util.java
test/com/sun/nio/sctp/SctpMultiChannel/Util.java
test/com/sun/nio/sctp/SctpServerChannel/Util.java

can be considered obsolete.

Regards,
Volker

On Tue, Jan 14, 2014 at 8:13 PM, Alan Bateman alan.bate...@oracle.comwrote:

 On 14/01/2014 16:57, Volker Simonis wrote:

 :

 test/com/sun/nio/sctp/SctpChannel/Util.java
 test/com/sun/nio/sctp/SctpMultiChannel/Util.java
 test/com/sun/nio/sctp/SctpServerChannel/Util.java

 - On AIX, we currently haven't implemented SCTP but we nevertheless

 compile the shared SCTP classes into the runtime class library. This
 way
 the AIX JDK can at least compile SCTP applications altough it can not
 run
 them. To support this scenario, the runtime check for the
 availability of
 SCTP has to be extended to catch UnsatisfiedLinkError and
 NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first
 time
 when the class SctpChannelImpl will be loaded because it cannot load
 the
 its native support library in the static initialisation section. On
 the
 next load attempt of the class, a NoClassDefFoundError will be thrown
 because of the previously failed initialisation.

  OS X has the same issue and the solution used there are stub
 implementations that just throw UOE. Details in 
 jdk/src/macosx/classes/sun/nio/ch/sctp
 and that maybe that would work for AIX too.

 -Alan.



Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

2014-01-14 Thread Alan Bateman

On 14/01/2014 16:57, Volker Simonis wrote:

:

test/com/sun/nio/sctp/SctpChannel/Util.java
test/com/sun/nio/sctp/SctpMultiChannel/Util.java
test/com/sun/nio/sctp/SctpServerChannel/Util.java

- On AIX, we currently haven't implemented SCTP but we nevertheless
compile the shared SCTP classes into the runtime class library. This way
the AIX JDK can at least compile SCTP applications altough it can not run
them. To support this scenario, the runtime check for the availability of
SCTP has to be extended to catch UnsatisfiedLinkError and
NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first time
when the class SctpChannelImpl will be loaded because it cannot load the
its native support library in the static initialisation section. On the
next load attempt of the class, a NoClassDefFoundError will be thrown
because of the previously failed initialisation.

OS X has the same issue and the solution used there are stub 
implementations that just throw UOE. Details in 
jdk/src/macosx/classes/sun/nio/ch/sctp and that maybe that would work 
for AIX too.


-Alan.