subject:"RFR\(L\)\: 8031581\: PPC64\: Addons and fixes for AIX to pass the jdk regression tests"

RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread Volker Simonis

Hi,

could you please review the following changes for the ppc-aix-port
stage/stage-9 repositories (the changes are planned for integration into
ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):

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

I've build and smoke tested without any problems on Linux/x86_64 and PPC64,
Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.

With these changes (and together with the changes from "8028537: PPC64:
Updated jdk/test scripts to understand the AIX os and environment" and
"8031134 : PPC64: implement printing on AIX") our port passes 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‎):

java/net/Inet6Address/B6558853.java
java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
java/nio/channels/Selector/RacyDeregister.java
sun/security/krb5/auto/Unreachable.java (only on IPv6)

Thank you and best regards,
Volker


Following a detailed description of the various changes:
src/share/native/java/util/zip/zip_util.c
src/share/native/sun/management/DiagnosticCommandImpl.c

   - According to ISO C it is perfectly legal for malloc to return zero if
   called with a zero argument. Fix various places where malloc can
   potentially correctly return zero because it was called with a zero
   argument.
   - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only
   fixes a compiler warning on Linux, but on AIX it prevents a VM crash later
   on because the return value of malloc() will be casted to int which is
   especially bad if that pointer was bigger than 32-bit.

make/CompileJavaClasses.gmk

   - Also use PollingWatchService on AIX.

make/lib/NioLibraries.gmk
src/aix/native/sun/nio/ch/AixNativeThread.c

   - Put the implementation for the native methods of NativeThread into
   AixNativeThread.c on AIX.

src/solaris/native/sun/nio/ch/PollArrayWrapper.c
src/solaris/native/sun/nio/ch/Net.c
src/aix/classes/sun/nio/ch/AixPollPort.java
src/aix/native/sun/nio/ch/AixPollPort.c
src/aix/native/java/net/aix_close.c

   - On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT,
   ...) are defined to different values than on other operating systems. The
   problem is however, that these constants are hardcoded as public final
   static members of various, shared Java classes. We therefore have to map
   them from Java to native every time before calling one of the native poll
   functions and back to Java after the call on AIX in order to get the right
   semantics.

src/share/classes/java/nio/file/CopyMoveHelper.java

   - As discussed on the core-libs mailing list (see
   
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html)
   it is not necessary to call Files.getFileAttributeView() with any
   linkOptions because at that place we've already checked that the target
   file can not be a symbolic link. This change makes the implementation more
   robust on platforms which support symbolic links but do not support the
   O_NOFOLLOW flag to the open system call. It also makes the JDK pass the
   demo/zipfs/basic.sh test on AIX.

src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java

   - Support "compound text" on AIX in the same way like on other Unix
   platforms.

src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider

   - Define the correct attach provider for AIX.

src/solaris/native/java/net/net_util_md.h
src/solaris/native/sun/nio/ch/FileDispatcherImpl.c
src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c

   - AIX needs a workaround for I/O cancellation (see:
   
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm).
   "..The close() subroutine is blocked until all subroutines which use the
   file descriptor return to usr space. For example, when a thread is calling
   close and another thread is calling select with the same file descriptor,
   the close subroutine does not return until the select call returns...". To
   fix this problem, we have to use the various NET_ wrappers which are
   declared in net_util_md.h and defined in aix_close.c and we also need
   some additional wrappers for fcntl(), read() and write() on AIX.
   While the current solution isn't really nice because it introduces some
   more AIX-specifc sections in shared code, I think it is the best way to go
   for JDK 8 because it imposes the smallest possible changes and risks for
   the existing platforms. I'm ready to change the code to unconditionally use
   the wrappers for all platforms and implement the wrappers empty on
   platforms which don't need any wrapping. I think it would also be nice to
   clean up the names (e.g. NET_Read() is currently a wrapper for recv()a

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread Alan Bateman


On 14/01/2014 08:40, Volker Simonis wrote:

Hi,

could you please review the following changes for the ppc-aix-port 
stage/stage-9 repositories (the changes are planned for integration 
into ppc-aix-port/stage-9 and subsequent backporting to 
ppc-aix-port/stage):
I'd like to review this but I won't have time until later in the week. 
From an initial look then there are a few things are not pretty (the 
changes to fix the AIX problems with I/O cancellation in particular) and 
I suspect that some refactoring is going to be required to handle some 
of this cleanly. A minor comment is that bug synopsis doesn't really 
communicate what these changes are about.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread Volker Simonis

Hi Alan,

On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote:

> On 14/01/2014 08:40, Volker Simonis wrote:
>
>> Hi,
>>
>> could you please review the following changes for the ppc-aix-port
>> stage/stage-9 repositories (the changes are planned for integration into
>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>>
>

>  I'd like to review this but I won't have time until later in the week.

Thanks, that would be great.

> From an initial look then there are a few things are not pretty (the
> changes to fix the AIX problems with I/O cancellation in particular) and I
> suspect that some refactoring is going to be required to handle some of
> this cleanly.

I agree, but as I wrote, this change is intended to finally go into both
jdk9 and jkd8u and I didn't wanted to do to much refactoring for jdk8u.
Once its in and we have a working port I'd be happy to work on refactoring
the code but I think this should be done in jdk9 where we have more time
and less risks of changing the behaviour on the existing platforms.

> A minor comment is that bug synopsis doesn't really communicate what these
> changes are about.
>
>
This is the last "bulk change" which address issues in several different
areas of the class library. Follow up changes will be more specific with
better bug synopsis (I promise :).

Regards,
Volker

> -Alan.
>

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread David Holmes


Just a note on this part (I havent looked at the code):


On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) 
are defined to different values than on other operating systems. The problem is 
however, that these constants are hardcoded as public final static members of 
various, shared Java classes.


Sounds like this should be handled the same way that the other "system 
constants" are handled - you can either store a platform file in the 
repo (for cross-compiling) or you generate the class containing the 
constants at build time.


David

On 14/01/2014 6:40 PM, Volker Simonis wrote:

Hi,

could you please review the following changes for the ppc-aix-port
stage/stage-9 repositories (the changes are planned for integration into
ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):

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

I've build and smoke tested without any problems on Linux/x86_64 and
PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.

With these changes (and together with the changes from "8028537: PPC64:
Updated jdk/test scripts to understand the AIX os and environment" and
"8031134 : PPC64: implement printing on AIX") our port passes 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
‎):

java/net/Inet6Address/B6558853.java
java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
java/nio/channels/Selector/RacyDeregister.java
sun/security/krb5/auto/Unreachable.java (only on IPv6)

Thank you and best regards,
Volker


Following a detailed description of the various changes:


src/share/native/java/util/zip/zip_util.c
src/share/native/sun/management/DiagnosticCommandImpl.c

  * According to ISO C it is perfectly legal for malloc to return zero
if called with a zero argument. Fix various places where malloc can
potentially correctly return zero because it was called with a zero
argument.
  * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This
only fixes a compiler warning on Linux, but on AIX it prevents a VM
crash later on because the return value of |malloc()| will be casted
to |int| which is especially bad if that pointer was bigger than
32-bit.


make/CompileJavaClasses.gmk

  * Also use |PollingWatchService| on AIX.


make/lib/NioLibraries.gmk
src/aix/native/sun/nio/ch/AixNativeThread.c

  * Put the implementation for the native methods of |NativeThread| into
|AixNativeThread.c| on AIX.


src/solaris/native/sun/nio/ch/PollArrayWrapper.c
src/solaris/native/sun/nio/ch/Net.c
src/aix/classes/sun/nio/ch/AixPollPort.java
src/aix/native/sun/nio/ch/AixPollPort.c
src/aix/native/java/net/aix_close.c

  * On AIX, the constants used for the polling events (i.e. |POLLIN|,
|POLLOUT|, ...) are defined to different values than on other
operating systems. The problem is however, that these constants are
hardcoded as public final static members of various, shared Java
classes. We therefore have to map them from Java to native every
time before calling one of the native poll functions and back to
Java after the call on AIX in order to get the right semantics.


src/share/classes/java/nio/file/CopyMoveHelper.java

  * As discussed on the core-libs mailing list (see

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html)
it is not necessary to call |Files.getFileAttributeView()| with any
|linkOptions| because at that place we've already checked that the
target file can not be a symbolic link. This change makes the
implementation more robust on platforms which support symbolic links
but do not support the |O_NOFOLLOW| flag to the |open| system call.
It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX.


src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java

  * Support "compound text" on AIX in the same way like on other Unix
platforms.



src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider

  * Define the correct attach provider for AIX.


src/solaris/native/java/net/net_util_md.h
src/solaris/native/sun/nio/ch/FileDispatcherImpl.c
src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c

  * AIX needs a workaround for I/O cancellation (see:

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm).
"..The |close()| subroutine is blocked until all subroutines which
use the file descriptor return to usr space. For example, when a
thread is calling close and another t

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread Volker Simonis

On Tue, Jan 14, 2014 at 12:29 PM, David Holmes wrote:

> Just a note on this part (I havent looked at the code):
>
>
>  On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT,
>> ...) are defined to different values than on other operating systems. The
>> problem is however, that these constants are hardcoded as public final
>> static members of various, shared Java classes.
>>
>
> Sounds like this should be handled the same way that the other "system
> constants" are handled - you can either store a platform file in the repo
> (for cross-compiling) or you generate the class containing the constants at
> build time.
>
>
Hi David,

thanks for your comments. That sound like a good idea but I'm not sure if
it would make sense to duplicate the following files:

src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java:
src/solaris/classes/sun/nio/ch/Port.java

because of this. Do you have a concrete example where Java-classes are
being generated with different constants in the class library build?

Both solutions would result in different class files on Aix and other Unix
variants. What do you think about assigning the concrete values depending
on 'os.name' in the static initializers of the corresponding classes? I
think that shouldn't introduce too much overhead and I could get rid of all
the ugly conversion code.

Regards,
Volker


> David
>
>
> On 14/01/2014 6:40 PM, Volker Simonis wrote:
>
>> Hi,
>>
>> could you please review the following changes for the ppc-aix-port
>> stage/stage-9 repositories (the changes are planned for integration into
>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
>>
>> I've build and smoke tested without any problems on Linux/x86_64 and
>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
>>
>> With these changes (and together with the changes from "8028537: PPC64:
>> Updated jdk/test scripts to understand the AIX os and environment" and
>> "8031134 : PPC64: implement printing on AIX") our port passes 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
>> ‎):
>>
>>
>> java/net/Inet6Address/B6558853.java
>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
>> java/nio/channels/Selector/RacyDeregister.java
>> sun/security/krb5/auto/Unreachable.java (only on IPv6)
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> Following a detailed description of the various changes:
>>
>>
>> src/share/native/java/util/zip/zip_util.c
>> src/share/native/sun/management/DiagnosticCommandImpl.c
>>
>>   * According to ISO C it is perfectly legal for malloc to return zero
>>
>> if called with a zero argument. Fix various places where malloc can
>> potentially correctly return zero because it was called with a zero
>> argument.
>>   * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This
>>
>> only fixes a compiler warning on Linux, but on AIX it prevents a VM
>> crash later on because the return value of |malloc()| will be casted
>> to |int| which is especially bad if that pointer was bigger than
>> 32-bit.
>>
>>
>> make/CompileJavaClasses.gmk
>>
>>   * Also use |PollingWatchService| on AIX.
>>
>>
>> make/lib/NioLibraries.gmk
>> src/aix/native/sun/nio/ch/AixNativeThread.c
>>
>>   * Put the implementation for the native methods of |NativeThread| into
>>
>> |AixNativeThread.c| on AIX.
>>
>>
>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c
>> src/solaris/native/sun/nio/ch/Net.c
>> src/aix/classes/sun/nio/ch/AixPollPort.java
>> src/aix/native/sun/nio/ch/AixPollPort.c
>> src/aix/native/java/net/aix_close.c
>>
>>   * On AIX, the constants used for the polling events (i.e. |POLLIN|,
>> |POLLOUT|, ...) are defined to different values than on other
>>
>> operating systems. The problem is however, that these constants are
>> hardcoded as public final static members of various, shared Java
>> classes. We therefore have to map them from Java to native every
>> time before calling one of the native poll functions and back to
>> Java after the call on AIX in order to get the right semantics.
>>
>>
>> src/share/classes/java/nio/file/CopyMoveHelper.java
>>
>>   * As discussed on the core-libs mailing list (see
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-
>> December/024119.html)
>> it is not necessary to call |Files.getFileAttributeView()| with any
>> |linkOptions| because at that place we've already checked that the
>> target file can not be a symbolic link. This change makes the
>>

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-14 Thread David Holmes


On 15/01/2014 12:10 AM, Volker Simonis wrote:

On Tue, Jan 14, 2014 at 12:29 PM, David Holmes mailto:david.hol...@oracle.com>> wrote:

Just a note on this part (I havent looked at the code):


On AIX, the constants used for the polling events (i.e. POLLIN,
POLLOUT, ...) are defined to different values than on other
operating systems. The problem is however, that these constants
are hardcoded as public final static members of various, shared
Java classes.


Sounds like this should be handled the same way that the other
"system constants" are handled - you can either store a platform
file in the repo (for cross-compiling) or you generate the class
containing the constants at build time.


Hi David,

thanks for your comments. That sound like a good idea but I'm not sure
if it would make sense to duplicate the following files:

src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java:
src/solaris/classes/sun/nio/ch/Port.java

because of this. Do you have a concrete example where Java-classes are
being generated with different constants in the class library build?


There are two files generated:

UnixConstants.java (or SolarisConstants.java) for general I/O type values
SocketOptionRegistry.java for socket options.

See jdk/make/gensrc/GensrcMisc.gmk.


Both solutions would result in different class files on Aix and other
Unix variants. What do you think about assigning the concrete values
depending on 'os.name ' in the static initializers of
the corresponding classes? I think that shouldn't introduce too much
overhead and I could get rid of all the ugly conversion code.


I'm not a fan of runtime checks of this kind though if it is only a very 
samll number of values it might be okay.


Another option would be to make those classes into "templates" as done 
with Version.java.template and substitute the right values at build time.


But I'll let Alan and net-dev folk come back with their preferred 
technique for this.


Cheers,
David



Regards,
Volker

David


On 14/01/2014 6:40 PM, Volker Simonis wrote:

Hi,

could you please review the following changes for the ppc-aix-port
stage/stage-9 repositories (the changes are planned for
integration into
ppc-aix-port/stage-9 and subsequent backporting to
ppc-aix-port/stage):

http://cr.openjdk.java.net/~__simonis/webrevs/8031581/


I've build and smoke tested without any problems on Linux/x86_64 and
PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.

With these changes (and together with the changes from "8028537:
PPC64:
Updated jdk/test scripts to understand the AIX os and
environment" and
"8031134 : PPC64: implement printing on AIX") our port passes
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

>‎):


java/net/Inet6Address/__B6558853.java
java/nio/channels/__AsynchronousChannelGroup/__Basic.java
(sporadically)
java/nio/channels/__AsynchronousChannelGroup/__GroupOfOne.java
java/nio/channels/__AsynchronousChannelGroup/__Unbounded.java
(sporadically)
java/nio/channels/Selector/__RacyDeregister.java
sun/security/krb5/auto/__Unreachable.java (only on IPv6)

Thank you and best regards,
Volker


Following a detailed description of the various changes:


 src/share/native/java/util/__zip/zip_util.c
 src/share/native/sun/__management/__DiagnosticCommandImpl.c

   * According to ISO C it is perfectly legal for malloc to
return zero

 if called with a zero argument. Fix various places where
malloc can
 potentially correctly return zero because it was called
with a zero
 argument.
   * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|.
This

 only fixes a compiler warning on Linux, but on AIX it
prevents a VM
 crash later on because the return value of |malloc()| will
be casted
 to |int| which is especially bad if that pointer was bigger
than
 32-bit.


 make/CompileJavaClasses.gmk

   * Also use |PollingWatchService| on AIX.


 make/lib/NioLibraries.gmk
 src/aix/native/sun/nio/ch/__AixNativeThread.c

   * Put the implementation for the native methods of
|NativeThread| into

 |AixNativeThread

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Staffan Larsen

Volker,

I’ve look at the following files:

src/share/native/sun/management/DiagnosticCommandImpl.c:
nit: “legel” -> “legal” (two times)
In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you 
allow dcmd_info_array to become NULL, then 
jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to 
check that.

src/solaris/native/sun/management/OperatingSystemImpl.c
No comments.

src/share/transport/socket/socketTransport.c
No comments.

src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
No comments.


Thanks,
/Staffan



On 14 jan 2014, at 09:40, Volker Simonis  wrote:

> Hi,
> 
> could you please review the following changes for the ppc-aix-port 
> stage/stage-9 repositories (the changes are planned for integration into 
> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
> 
> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
> 
> I've build and smoke tested without any problems on Linux/x86_64 and PPC64, 
> Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
> 
> With these changes (and together with the changes from "8028537: PPC64: 
> Updated jdk/test scripts to understand the AIX os and environment" and 
> "8031134 : PPC64: implement printing on AIX") our port passes 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‎):
> 
> java/net/Inet6Address/B6558853.java
> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
> java/nio/channels/Selector/RacyDeregister.java
> sun/security/krb5/auto/Unreachable.java (only on IPv6)
> 
> Thank you and best regards,
> Volker
> 
> 
> Following a detailed description of the various changes:
> src/share/native/java/util/zip/zip_util.c
> src/share/native/sun/management/DiagnosticCommandImpl.c
> 
> According to ISO C it is perfectly legal for malloc to return zero if called 
> with a zero argument. Fix various places where malloc can potentially 
> correctly return zero because it was called with a zero argument.
> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a 
> compiler warning on Linux, but on AIX it prevents a VM crash later on because 
> the return value of malloc() will be casted to int which is especially bad if 
> that pointer was bigger than 32-bit.
> make/CompileJavaClasses.gmk
> 
> Also use PollingWatchService on AIX.
> make/lib/NioLibraries.gmk
> src/aix/native/sun/nio/ch/AixNativeThread.c
> 
> Put the implementation for the native methods of NativeThread into 
> AixNativeThread.c on AIX.
> src/solaris/native/sun/nio/ch/PollArrayWrapper.c
> src/solaris/native/sun/nio/ch/Net.c
> src/aix/classes/sun/nio/ch/AixPollPort.java
> src/aix/native/sun/nio/ch/AixPollPort.c
> src/aix/native/java/net/aix_close.c
> 
> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) 
> are defined to different values than on other operating systems. The problem 
> is however, that these constants are hardcoded as public final static members 
> of various, shared Java classes. We therefore have to map them from Java to 
> native every time before calling one of the native poll functions and back to 
> Java after the call on AIX in order to get the right semantics.
> src/share/classes/java/nio/file/CopyMoveHelper.java
> 
> As discussed on the core-libs mailing list (see 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html)
>  it is not necessary to call Files.getFileAttributeView() with any 
> linkOptions because at that place we've already checked that the target file 
> can not be a symbolic link. This change makes the implementation more robust 
> on platforms which support symbolic links but do not support the O_NOFOLLOW 
> flag to the open system call. It also makes the JDK pass the 
> demo/zipfs/basic.sh test on AIX.
> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
> 
> Support "compound text" on AIX in the same way like on other Unix platforms.
> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
> 
> Define the correct attach provider for AIX.
> src/solaris/native/java/net/net_util_md.h
> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c
> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c
> 
> AIX needs a workaround for I/O cancellation (see: 
> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm).
>  "..The close() subroutine is blocked until all subroutines which use the 
> file descriptor return to usr space. For example, when a thread is calling 
> close and another thread is calling select with the same file descriptor, the 
> close subroutine does not return until the select call returns...". To fix 
> this pro

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Alan Bateman


On 15/01/2014 06:24, David Holmes wrote:


I'm not a fan of runtime checks of this kind though if it is only a 
very samll number of values it might be okay.


Another option would be to make those classes into "templates" as done 
with Version.java.template and substitute the right values at build time.


But I'll let Alan and net-dev folk come back with their preferred 
technique for this.


I plan to spend time on Volker's webrev later in the week (just too busy 
with other things right now). For the translation issue then it's an 
oversight in the original implementation, it just hasn't come up before 
(to my knowledge anyway). The simplest solution here maybe to to just 
move them to sun.net.ch.Net and have them initialized to their native 
value. In general then I'm not too concerned about that one, it's the 
changes to support async close on AIX that are leaping out at me.


-Alan

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Volker Simonis

On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote:

> On 15/01/2014 06:24, David Holmes wrote:
>
>>
>> I'm not a fan of runtime checks of this kind though if it is only a very
>> samll number of values it might be okay.
>>
>> Another option would be to make those classes into "templates" as done
>> with Version.java.template and substitute the right values at build time.
>>
>> But I'll let Alan and net-dev folk come back with their preferred
>> technique for this.
>>
>>  I plan to spend time on Volker's webrev later in the week (just too busy
> with other things right now). For the translation issue then it's an
> oversight in the original implementation, it just hasn't come up before (to
> my knowledge anyway). The simplest solution here maybe to to just move them
> to sun.net.ch.Net and have them initialized to their native value.


Do you mean sun.nio.ch.Net right?

Do you propose to completely remove the definitions of the POLL constants
from:

src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java
src/solaris/classes/sun/nio/ch/Port.java

and replace all their usages by Net.POLL* ?


> In general then I'm not too concerned about that one, it's the changes to
> support async close on AIX that are leaping out at me.
>
> -Alan
>

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Volker Simonis

Hi Staffan,

thanks for the review. Please find my comments inline:

On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen
wrote:

> Volker,
>
> I’ve look at the following files:
>
> src/share/native/sun/management/DiagnosticCommandImpl.c:
> nit: “legel” -> “legal” (two times)
> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if
> you allow dcmd_info_array to become NULL,
> then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you
> need to check that.
>

Good catch. I actually had problems with malloc returning NULL in
'getDiagnosticCommandArgumentInfoArray()' and then changed all other
potentially dangerous locations which used the same pattern.

However I think if the 'dcmd_info_array' has zero length it would be
perfectly fine to return a zero length array. So what about the following
solution:

  dcmdInfoCls = (*env)->FindClass(env,
  "sun/management/DiagnosticCommandInfo");
  num_commands = (*env)->GetArrayLength(env, commands);
  if (num_commands = 0) {
  result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL);
  if (result == NULL) {
  JNU_ThrowOutOfMemoryError(env, 0);
  }
  else {
  return result;
  }
  }
  dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
  if (dcmd_info_array == NULL) {
  JNU_ThrowOutOfMemoryError(env, NULL);
  }
  jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
  result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);

That seems easier and saves me from handling the exception.

What do you think?

src/solaris/native/sun/management/OperatingSystemImpl.c
> No comments.
>
> src/share/transport/socket/socketTransport.c
> No comments.
>
>
> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
> No comments.
>
>
> Thanks,
> /Staffan
>
>
>
> On 14 jan 2014, at 09:40, Volker Simonis  wrote:
>
> Hi,
>
> could you please review the following changes for the ppc-aix-port
> stage/stage-9 repositories (the changes are planned for integration into
> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>
> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
>
> I've build and smoke tested without any problems on Linux/x86_64 and
> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
>
> With these changes (and together with the changes from "8028537: PPC64:
> Updated jdk/test scripts to understand the AIX os and environment" and
> "8031134 : PPC64: implement printing on AIX") our port passes 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‎):
>
> java/net/Inet6Address/B6558853.java
> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
> java/nio/channels/Selector/RacyDeregister.java
> sun/security/krb5/auto/Unreachable.java (only on IPv6)
>
> Thank you and best regards,
> Volker
>
>
> Following a detailed description of the various changes:
>  src/share/native/java/util/zip/zip_util.c
> src/share/native/sun/management/DiagnosticCommandImpl.c
>
>- According to ISO C it is perfectly legal for malloc to return zero
>if called with a zero argument. Fix various places where malloc can
>potentially correctly return zero because it was called with a zero
>argument.
>- Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only
>fixes a compiler warning on Linux, but on AIX it prevents a VM crash later
>on because the return value of malloc() will be casted to int which is
>especially bad if that pointer was bigger than 32-bit.
>
> make/CompileJavaClasses.gmk
>
>- Also use PollingWatchService on AIX.
>
> make/lib/NioLibraries.gmk
> src/aix/native/sun/nio/ch/AixNativeThread.c
>
>- Put the implementation for the native methods of NativeThread into
>AixNativeThread.c on AIX.
>
> src/solaris/native/sun/nio/ch/PollArrayWrapper.c
> src/solaris/native/sun/nio/ch/Net.c
> src/aix/classes/sun/nio/ch/AixPollPort.java
> src/aix/native/sun/nio/ch/AixPollPort.c
> src/aix/native/java/net/aix_close.c
>
>- On AIX, the constants used for the polling events (i.e. POLLIN,
>POLLOUT, ...) are defined to different values than on other operating
>systems. The problem is however, that these constants are hardcoded as
>public final static members of various, shared Java classes. We therefore
>have to map them from Java to native every time before calling one of the
>native poll functions and back to Java after the call on AIX in order to
>get the right semantics.
>
> src/share/classes/java/nio/file/CopyMoveHelper.java
>
>- As discussed on the core-libs mailing list (see
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.ht

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Volker Simonis

On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
 wrote:
> Hi Staffan,
>
> thanks for the review. Please find my comments inline:
>
> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen 
> wrote:
>>
>> Volker,
>>
>> I’ve look at the following files:
>>
>> src/share/native/sun/management/DiagnosticCommandImpl.c:
>> nit: “legel” -> “legal” (two times)
>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if
>> you allow dcmd_info_array to become NULL, then
>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to
>> check that.
>
>
> Good catch. I actually had problems with malloc returning NULL in
> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other
> potentially dangerous locations which used the same pattern.
>
> However I think if the 'dcmd_info_array' has zero length it would be
> perfectly fine to return a zero length array. So what about the following
> solution:
>
>   dcmdInfoCls = (*env)->FindClass(env,
>   "sun/management/DiagnosticCommandInfo");
>   num_commands = (*env)->GetArrayLength(env, commands);

Sorry, of course I wanted to say "if (num_commands == 0)" here!

>   if (num_commands = 0) {
>   result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL);
>   if (result == NULL) {
>   JNU_ThrowOutOfMemoryError(env, 0);
>   }
>   else {
>   return result;
>   }
>   }
>   dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
>   if (dcmd_info_array == NULL) {
>   JNU_ThrowOutOfMemoryError(env, NULL);
>   }
>   jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
>   result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
>
> That seems easier and saves me from handling the exception.
>
> What do you think?
>
>> src/solaris/native/sun/management/OperatingSystemImpl.c
>> No comments.
>>
>> src/share/transport/socket/socketTransport.c
>> No comments.
>>
>>
>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
>> No comments.
>>
>>
>> Thanks,
>> /Staffan
>>
>>
>>
>> On 14 jan 2014, at 09:40, Volker Simonis  wrote:
>>
>> Hi,
>>
>> could you please review the following changes for the ppc-aix-port
>> stage/stage-9 repositories (the changes are planned for integration into
>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
>>
>> I've build and smoke tested without any problems on Linux/x86_64 and
>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
>>
>> With these changes (and together with the changes from "8028537: PPC64:
>> Updated jdk/test scripts to understand the AIX os and environment" and
>> "8031134 : PPC64: implement printing on AIX") our port passes 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‎):
>>
>> java/net/Inet6Address/B6558853.java
>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
>> java/nio/channels/Selector/RacyDeregister.java
>> sun/security/krb5/auto/Unreachable.java (only on IPv6)
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> Following a detailed description of the various changes:
>>
>> src/share/native/java/util/zip/zip_util.c
>> src/share/native/sun/management/DiagnosticCommandImpl.c
>>
>> According to ISO C it is perfectly legal for malloc to return zero if
>> called with a zero argument. Fix various places where malloc can potentially
>> correctly return zero because it was called with a zero argument.
>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a
>> compiler warning on Linux, but on AIX it prevents a VM crash later on
>> because the return value of malloc() will be casted to int which is
>> especially bad if that pointer was bigger than 32-bit.
>>
>> make/CompileJavaClasses.gmk
>>
>> Also use PollingWatchService on AIX.
>>
>> make/lib/NioLibraries.gmk
>> src/aix/native/sun/nio/ch/AixNativeThread.c
>>
>> Put the implementation for the native methods of NativeThread into
>> AixNativeThread.c on AIX.
>>
>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c
>> src/solaris/native/sun/nio/ch/Net.c
>> src/aix/classes/sun/nio/ch/AixPollPort.java
>> src/aix/native/sun/nio/ch/AixPollPort.c
>> src/aix/native/java/net/aix_close.c
>>
>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT,
>> ...) are defined to different values than on other operating systems. The
>> problem is however, that these constants are hardcoded as public final
>> static members of various, shared Java classes. We therefore have to map
>> them from Java to native every time before calling one of the native poll
>> functions and back to Java after the call on AIX in order to get

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Volker Simonis

On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis 
wrote:
> On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
>  wrote:
>> Hi Staffan,
>>
>> thanks for the review. Please find my comments inline:
>>
>> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen <
staffan.lar...@oracle.com>
>> wrote:
>>>
>>> Volker,
>>>
>>> I’ve look at the following files:
>>>
>>> src/share/native/sun/management/DiagnosticCommandImpl.c:
>>> nit: “legel” -> “legal” (two times)
>>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo()
if
>>> you allow dcmd_info_array to become NULL, then
>>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you
need to
>>> check that.
>>
>>
>> Good catch. I actually had problems with malloc returning NULL in
>> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other
>> potentially dangerous locations which used the same pattern.
>>
>> However I think if the 'dcmd_info_array' has zero length it would be
>> perfectly fine to return a zero length array. So what about the following
>> solution:
>>

Sorry for the noise - it seems I was a little indisposed during the last
mails:)
So this is the simple change I'd like to propose for
Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo():


@@ -117,19 +119,23 @@
   return NULL;
   }
   num_commands = (*env)->GetArrayLength(env, commands);
-  dcmd_info_array = (dcmdInfo*) malloc(num_commands *
-   sizeof(dcmdInfo));
+  dcmdInfoCls = (*env)->FindClass(env,
+  "sun/management/DiagnosticCommandInfo");
+  result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
+  if (result == NULL) {
+  JNU_ThrowOutOfMemoryError(env, 0);
+  }
+  if (num_commands == 0) {
+  /* Handle the 'zero commands' case specially to avoid calling
'malloc()' */
+  /* with a zero argument because that may legally return a NULL
pointer.  */
+  return result;
+  }
+  dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
   if (dcmd_info_array == NULL) {
   JNU_ThrowOutOfMemoryError(env, NULL);
   }
   jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
-  dcmdInfoCls = (*env)->FindClass(env,
-  "sun/management/DiagnosticCommandInfo");
-  result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
-  if (result == NULL) {
-  free(dcmd_info_array);
-  JNU_ThrowOutOfMemoryError(env, 0);
-  }
   for (i=0; iGetObjectArrayElement(env,commands,i),

If the 'commands' input array is of zero length just return a zero length
array.
OK?

>>   dcmdInfoCls = (*env)->FindClass(env,
>>
"sun/management/DiagnosticCommandInfo");
>>   num_commands = (*env)->GetArrayLength(env, commands);
>
> Sorry, of course I wanted to say "if (num_commands == 0)" here!
>
>>   if (num_commands = 0) {
>>   result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL);
>>   if (result == NULL) {
>>   JNU_ThrowOutOfMemoryError(env, 0);
>>   }
>>   else {
>>   return result;
>>   }
>>   }
>>   dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
>>   if (dcmd_info_array == NULL) {
>>   JNU_ThrowOutOfMemoryError(env, NULL);
>>   }
>>   jmm_interface->GetDiagnosticCommandInfo(env, commands,
dcmd_info_array);
>>   result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
>>
>> That seems easier and saves me from handling the exception.
>>
>> What do you think?
>>
>>> src/solaris/native/sun/management/OperatingSystemImpl.c
>>> No comments.
>>>
>>> src/share/transport/socket/socketTransport.c
>>> No comments.
>>>
>>>
>>>
src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
>>> No comments.
>>>
>>>
>>> Thanks,
>>> /Staffan
>>>
>>>
>>>
>>> On 14 jan 2014, at 09:40, Volker Simonis 
wrote:
>>>
>>> Hi,
>>>
>>> could you please review the following changes for the ppc-aix-port
>>> stage/stage-9 repositories (the changes are planned for integration into
>>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
>>>
>>> I've build and smoke tested without any problems on Linux/x86_64 and
>>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
>>>
>>> With these changes (and together with the changes from "8028537: PPC64:
>>> Updated jdk/test scripts to understand the AIX os and environment" and
>>> "8031134 : PPC64: implement printing on AIX") our port passes 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‎):
>>>
>>> java/net/Inet6Address/B6558853.java
>>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
>>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
>>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
>>> java/nio/channels/Selector/RacyDere

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Staffan Larsen

Yes, that looks like a good solution.

/Staffan

On 15 jan 2014, at 17:34, Volker Simonis  wrote:

> Hi Staffan,
> 
> thanks for the review. Please find my comments inline:
> 
> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen  
> wrote:
> Volker,
> 
> I’ve look at the following files:
> 
> src/share/native/sun/management/DiagnosticCommandImpl.c:
> nit: “legel” -> “legal” (two times)
> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if 
> you allow dcmd_info_array to become NULL, then 
> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to 
> check that.
> 
> Good catch. I actually had problems with malloc returning NULL in 
> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other 
> potentially dangerous locations which used the same pattern.
> 
> However I think if the 'dcmd_info_array' has zero length it would be 
> perfectly fine to return a zero length array. So what about the following 
> solution:
> 
>   dcmdInfoCls = (*env)->FindClass(env,
>   "sun/management/DiagnosticCommandInfo");
>   num_commands = (*env)->GetArrayLength(env, commands);
>   if (num_commands = 0) {
>   result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL);
>   if (result == NULL) {
>   JNU_ThrowOutOfMemoryError(env, 0);
>   }
>   else {
>   return result;
>   }
>   }
>   dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
>   if (dcmd_info_array == NULL) {
>   JNU_ThrowOutOfMemoryError(env, NULL);
>   }
>   jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
>   result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
> 
> That seems easier and saves me from handling the exception.
> 
> What do you think?
> 
> src/solaris/native/sun/management/OperatingSystemImpl.c
> No comments.
> 
> src/share/transport/socket/socketTransport.c
> No comments.
> 
> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
> No comments.
> 
> 
> Thanks,
> /Staffan
> 
> 
> 
> On 14 jan 2014, at 09:40, Volker Simonis  wrote:
> 
>> Hi,
>> 
>> could you please review the following changes for the ppc-aix-port 
>> stage/stage-9 repositories (the changes are planned for integration into 
>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
>> 
>> I've build and smoke tested without any problems on Linux/x86_64 and PPC64, 
>> Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
>> 
>> With these changes (and together with the changes from "8028537: PPC64: 
>> Updated jdk/test scripts to understand the AIX os and environment" and 
>> "8031134 : PPC64: implement printing on AIX") our port passes 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‎):
>> 
>> java/net/Inet6Address/B6558853.java
>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
>> java/nio/channels/Selector/RacyDeregister.java
>> sun/security/krb5/auto/Unreachable.java (only on IPv6)
>> 
>> Thank you and best regards,
>> Volker
>> 
>> 
>> Following a detailed description of the various changes:
>> src/share/native/java/util/zip/zip_util.c
>> src/share/native/sun/management/DiagnosticCommandImpl.c
>> 
>> According to ISO C it is perfectly legal for malloc to return zero if called 
>> with a zero argument. Fix various places where malloc can potentially 
>> correctly return zero because it was called with a zero argument.
>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a 
>> compiler warning on Linux, but on AIX it prevents a VM crash later on 
>> because the return value of malloc() will be casted to int which is 
>> especially bad if that pointer was bigger than 32-bit.
>> make/CompileJavaClasses.gmk
>> 
>> Also use PollingWatchService on AIX.
>> make/lib/NioLibraries.gmk
>> src/aix/native/sun/nio/ch/AixNativeThread.c
>> 
>> Put the implementation for the native methods of NativeThread into 
>> AixNativeThread.c on AIX.
>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c
>> src/solaris/native/sun/nio/ch/Net.c
>> src/aix/classes/sun/nio/ch/AixPollPort.java
>> src/aix/native/sun/nio/ch/AixPollPort.c
>> src/aix/native/java/net/aix_close.c
>> 
>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, 
>> ...) are defined to different values than on other operating systems. The 
>> problem is however, that these constants are hardcoded as public final 
>> static members of various, shared Java classes. We therefore have to map 
>> them from Java to native every time before calling one of the native poll 
>> functions and back to Java after the call on AIX in order to get the right 
>>

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Staffan Larsen


On 15 jan 2014, at 18:27, Volker Simonis  wrote:

> On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
>  wrote:
>> Hi Staffan,
>> 
>> thanks for the review. Please find my comments inline:
>> 
>> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen 
>> wrote:
>>> 
>>> Volker,
>>> 
>>> I’ve look at the following files:
>>> 
>>> src/share/native/sun/management/DiagnosticCommandImpl.c:
>>> nit: “legel” -> “legal” (two times)
>>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if
>>> you allow dcmd_info_array to become NULL, then
>>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to
>>> check that.
>> 
>> 
>> Good catch. I actually had problems with malloc returning NULL in
>> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other
>> potentially dangerous locations which used the same pattern.
>> 
>> However I think if the 'dcmd_info_array' has zero length it would be
>> perfectly fine to return a zero length array. So what about the following
>> solution:
>> 
>>  dcmdInfoCls = (*env)->FindClass(env,
>>  "sun/management/DiagnosticCommandInfo");
>>  num_commands = (*env)->GetArrayLength(env, commands);
> 
> Sorry, of course I wanted to say "if (num_commands == 0)" here!

I understood as much :-)

> 
>>  if (num_commands = 0) {
>>  result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL);
>>  if (result == NULL) {
>>  JNU_ThrowOutOfMemoryError(env, 0);
>>  }
>>  else {
>>  return result;
>>  }
>>  }
>>  dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
>>  if (dcmd_info_array == NULL) {
>>  JNU_ThrowOutOfMemoryError(env, NULL);
>>  }
>>  jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
>>  result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
>> 
>> That seems easier and saves me from handling the exception.
>> 
>> What do you think?
>> 
>>> src/solaris/native/sun/management/OperatingSystemImpl.c
>>> No comments.
>>> 
>>> src/share/transport/socket/socketTransport.c
>>> No comments.
>>> 
>>> 
>>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
>>> No comments.
>>> 
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>>> 
>>> On 14 jan 2014, at 09:40, Volker Simonis  wrote:
>>> 
>>> Hi,
>>> 
>>> could you please review the following changes for the ppc-aix-port
>>> stage/stage-9 repositories (the changes are planned for integration into
>>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
>>> 
>>> I've build and smoke tested without any problems on Linux/x86_64 and
>>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
>>> 
>>> With these changes (and together with the changes from "8028537: PPC64:
>>> Updated jdk/test scripts to understand the AIX os and environment" and
>>> "8031134 : PPC64: implement printing on AIX") our port passes 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‎):
>>> 
>>> java/net/Inet6Address/B6558853.java
>>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically)
>>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
>>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically)
>>> java/nio/channels/Selector/RacyDeregister.java
>>> sun/security/krb5/auto/Unreachable.java (only on IPv6)
>>> 
>>> Thank you and best regards,
>>> Volker
>>> 
>>> 
>>> Following a detailed description of the various changes:
>>> 
>>> src/share/native/java/util/zip/zip_util.c
>>> src/share/native/sun/management/DiagnosticCommandImpl.c
>>> 
>>> According to ISO C it is perfectly legal for malloc to return zero if
>>> called with a zero argument. Fix various places where malloc can potentially
>>> correctly return zero because it was called with a zero argument.
>>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a
>>> compiler warning on Linux, but on AIX it prevents a VM crash later on
>>> because the return value of malloc() will be casted to int which is
>>> especially bad if that pointer was bigger than 32-bit.
>>> 
>>> make/CompileJavaClasses.gmk
>>> 
>>> Also use PollingWatchService on AIX.
>>> 
>>> make/lib/NioLibraries.gmk
>>> src/aix/native/sun/nio/ch/AixNativeThread.c
>>> 
>>> Put the implementation for the native methods of NativeThread into
>>> AixNativeThread.c on AIX.
>>> 
>>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c
>>> src/solaris/native/sun/nio/ch/Net.c
>>> src/aix/classes/sun/nio/ch/AixPollPort.java
>>> src/aix/native/sun/nio/ch/AixPollPort.c
>>> src/aix/native/java/net/aix_close.c
>>> 
>>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT,
>>> ...) are defined to different values than on other operating systems. The
>>> problem is however, that these constants are hardcoded a

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-15 Thread Staffan Larsen


On 15 jan 2014, at 18:52, Volker Simonis  wrote:

> 
> 
> On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis  
> wrote:
> > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis
> >  wrote:
> >> Hi Staffan,
> >>
> >> thanks for the review. Please find my comments inline:
> >>
> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen 
> >> wrote:
> >>>
> >>> Volker,
> >>>
> >>> I’ve look at the following files:
> >>>
> >>> src/share/native/sun/management/DiagnosticCommandImpl.c:
> >>> nit: “legel” -> “legal” (two times)
> >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if
> >>> you allow dcmd_info_array to become NULL, then
> >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need 
> >>> to
> >>> check that.
> >>
> >>
> >> Good catch. I actually had problems with malloc returning NULL in
> >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other
> >> potentially dangerous locations which used the same pattern.
> >>
> >> However I think if the 'dcmd_info_array' has zero length it would be
> >> perfectly fine to return a zero length array. So what about the following
> >> solution:
> >>
> 
> Sorry for the noise - it seems I was a little indisposed during the last 
> mails:)
> So this is the simple change I'd like to propose for 
> Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo():
> 
> 
> @@ -117,19 +119,23 @@
>return NULL;
>}
>num_commands = (*env)->GetArrayLength(env, commands);
> -  dcmd_info_array = (dcmdInfo*) malloc(num_commands *
> -   sizeof(dcmdInfo));
> +  dcmdInfoCls = (*env)->FindClass(env,
> +  "sun/management/DiagnosticCommandInfo");
> +  result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
> +  if (result == NULL) {
> +  JNU_ThrowOutOfMemoryError(env, 0);
> +  }
> +  if (num_commands == 0) {
> +  /* Handle the 'zero commands' case specially to avoid calling 
> 'malloc()' */
> +  /* with a zero argument because that may legally return a NULL 
> pointer.  */
> +  return result;
> +  }
> +  dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
>if (dcmd_info_array == NULL) {
>JNU_ThrowOutOfMemoryError(env, NULL);
>}
>jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
> -  dcmdInfoCls = (*env)->FindClass(env,
> -  "sun/management/DiagnosticCommandInfo");
> -  result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
> -  if (result == NULL) {
> -  free(dcmd_info_array);
> -  JNU_ThrowOutOfMemoryError(env, 0);
> -  }
>for (i=0; iargs = getDiagnosticCommandArgumentInfoArray(env,
> 
> (*env)->GetObjectArrayElement(env,commands,i),
> 
> If the 'commands' input array is of zero length just return a zero length 
> array.
> OK?

Yes, this looks good (still :-) )

/Staffan


> 
> >>   dcmdInfoCls = (*env)->FindClass(env,
> >>   "sun/management/DiagnosticCommandInfo");
> >>   num_commands = (*env)->GetArrayLength(env, commands);
> >
> > Sorry, of course I wanted to say "if (num_commands == 0)" here!
> >
> >>   if (num_commands = 0) {
> >>   result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL);
> >>   if (result == NULL) {
> >>   JNU_ThrowOutOfMemoryError(env, 0);
> >>   }
> >>   else {
> >>   return result;
> >>   }
> >>   }
> >>   dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo));
> >>   if (dcmd_info_array == NULL) {
> >>   JNU_ThrowOutOfMemoryError(env, NULL);
> >>   }
> >>   jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array);
> >>   result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL);
> >>
> >> That seems easier and saves me from handling the exception.
> >>
> >> What do you think?
> >>
> >>> src/solaris/native/sun/management/OperatingSystemImpl.c
> >>> No comments.
> >>>
> >>> src/share/transport/socket/socketTransport.c
> >>> No comments.
> >>>
> >>>
> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
> >>> No comments.
> >>>
> >>>
> >>> Thanks,
> >>> /Staffan
> >>>
> >>>
> >>>
> >>> On 14 jan 2014, at 09:40, Volker Simonis  wrote:
> >>>
> >>> Hi,
> >>>
> >>> could you please review the following changes for the ppc-aix-port
> >>> stage/stage-9 repositories (the changes are planned for integration into
> >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
> >>>
> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/
> >>>
> >>> I've build and smoke tested without any problems on Linux/x86_64 and
> >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64.
> >>>
> >>> With these changes (and together with the changes from "8028537: PPC64:
> >>> Updated jdk/test scripts to understand the AIX os and environment" and
> >>> "8031134 :

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Volker Simonis

On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis
wrote:

>
>
>
> On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote:
>
>> On 15/01/2014 06:24, David Holmes wrote:
>>
>>>
>>> I'm not a fan of runtime checks of this kind though if it is only a very
>>> samll number of values it might be okay.
>>>
>>> Another option would be to make those classes into "templates" as done
>>> with Version.java.template and substitute the right values at build time.
>>>
>>> But I'll let Alan and net-dev folk come back with their preferred
>>> technique for this.
>>>
>>>  I plan to spend time on Volker's webrev later in the week (just too
>> busy with other things right now). For the translation issue then it's an
>> oversight in the original implementation, it just hasn't come up before (to
>> my knowledge anyway). The simplest solution here maybe to to just move them
>> to sun.net.ch.Net and have them initialized to their native value.
>
>
> Do you mean sun.nio.ch.Net right?
>
> Do you propose to completely remove the definitions of the POLL constants
> from:
>
> src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java
>  src/solaris/classes/sun/nio/ch/Port.java
>
> and replace all their usages by Net.POLL* ?
>
>

Hi Alan,

I think sun.nio.ch.IOUtil seems even more appropriate to me for these
constants. What do you think?

Would it be OK for you if I initialize them right in the static initializer
of  IOUtil based on "os.name" or do you prefer to have native methods which
return the right constants?

Regards,
Volker


> In general then I'm not too concerned about that one, it's the changes to
>> support async close on AIX that are leaping out at me.
>>
>> -Alan
>>
>
>

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Alan Bateman


On 16/01/2014 09:38, Volker Simonis wrote:



Hi Alan,

I think sun.nio.ch.IOUtil seems even more appropriate to me for these 
constants. What do you think?


Would it be OK for you if I initialize them right in the static 
initializer of  IOUtil based on "os.name " or do you 
prefer to have native methods which return the right constants?
I have a small preference for sun.nio.ch.Net because these constants are 
used with Net.poll. Would you be open to separating this one from the 
AIX changes? The reason is that it isn't AIX specific, rather just an 
oversight that hasn't been an issue because it doesn't impact other 
platforms. Using os.name initially would be okay although we could 
change that over time.


-Alan

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Volker Simonis

On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman  wrote:
> On 16/01/2014 09:38, Volker Simonis wrote:
>
>
>
> Hi Alan,
>
> I think sun.nio.ch.IOUtil seems even more appropriate to me for these
> constants. What do you think?
>
> Would it be OK for you if I initialize them right in the static initializer
> of  IOUtil based on "os.name" or do you prefer to have native methods which
> return the right constants?
>
> I have a small preference for sun.nio.ch.Net because these constants are
> used with Net.poll.

I just thought because poll is more file-descriptor oriented and not
network specific. And the constants are also used for example in:

src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java:
src/solaris/classes/sun/nio/ch/sctp/Sctp*
src/solaris/classes/sun/nio/ch/Port.java

But actually I have no prefernece here so I can put them just as well
to sun.nio.ch.Net

> Would you be open to separating this one from the AIX
> changes? The reason is that it isn't AIX specific, rather just an oversight
> that hasn't been an issue because it doesn't impact other platforms.

Sure, no problem. Although I still would like to push this to
ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where
we really need it. Anyway, the current plan is to merge
ppc-aix-port/stage-9 into jdk9 mainline by the end of January and
ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would
that be ok?

> Using
> os.name initially would be okay although we could change that over time.

I've already written the native methods:)

>
> -Alan

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Alan Bateman


On 16/01/2014 10:34, Volker Simonis wrote:

:
I just thought because poll is more file-descriptor oriented and not
network specific. And the constants are also used for example in:

src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java:
src/solaris/classes/sun/nio/ch/sctp/Sctp*
src/solaris/classes/sun/nio/ch/Port.java

But actually I have no prefernece here so I can put them just as well
to sun.nio.ch.Net
It's not used for anything except sockets here (there aren't any 
selectable channels that aren't also network channels). So I think 
sun.nio.ch.Net is marginly cleaner here.




:

Sure, no problem. Although I still would like to push this to
ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where
we really need it. Anyway, the current plan is to merge
ppc-aix-port/stage-9 into jdk9 mainline by the end of January and
ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would
that be ok?

I see you've created a bug for this. I guess it's okay if comes via the 
ppc port although would still be good to get it into jdk9/dev early as 
it impacts all platforms.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-17 Thread Volker Simonis

On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman  wrote:
> On 14/01/2014 08:40, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please review the following changes for the ppc-aix-port
>> stage/stage-9 repositories (the changes are planned for integration into
>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>
> I'd like to review this but I won't have time until later in the week. From
> an initial look then there are a few things are not pretty (the changes to
> fix the AIX problems with I/O cancellation in particular) and I suspect that
> some refactoring is going to be required to handle some of this cleanly. A
> minor comment is that bug synopsis doesn't really communicate what these
> changes are about.
>
> -Alan.

Just forwarded the following message from another thread here where it belongs:

On 17/01/2014 16:57, Alan Bateman wrote:

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

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-20 Thread Volker Simonis

On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis
 wrote:
> On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman  
> wrote:
>> On 14/01/2014 08:40, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> could you please review the following changes for the ppc-aix-port
>>> stage/stage-9 repositories (the changes are planned for integration into
>>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage):
>>
>> I'd like to review this but I won't have time until later in the week. From
>> an initial look then there are a few things are not pretty (the changes to
>> fix the AIX problems with I/O cancellation in particular) and I suspect that
>> some refactoring is going to be required to handle some of this cleanly. A
>> minor comment is that bug synopsis doesn't really communicate what these
>> changes are about.
>>
>> -Alan.
>
> Just forwarded the following message from another thread here where it 
> belongs:
>
> On 17/01/2014 16:57, Alan Bateman wrote:
>
> 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).

> On 17/01/2014 21:23, Volker Simonis wrote:
>
> > You're right, one race is with preClose/dup2 but also with other calls
> > like read/fcntl/...
> >
> > There were several tests that failed and once I fixed it they all
> > succeeded. But I can recreate some of the failures for you. The
> > symptoms are always the same: the VMis locked. If you trigger a stack
> > trace you can see that at least on thread is blocked in a I/O
> > operation on a file descriptor like fcntl (e.g. for file locking),
> > read, etc. while another thread is trying to close that socket.
> >
>
> As it happens, we have some carry over issues from the Mac port,
> one of which is that async close of FileChannels will block
> indefinitely in dup2 when there is another thread blocked (on
> fnctl or reading from a pipe ...). I haven't time time to work on
> it but this discussion has reminded me that we need to sort it
> out. I've put a preliminary webrev with the changes here:
>
> http://cr.openjdk.java.net/~alanb/7133499/webrev/
>
> The important part is that it's using signal consistently on
> Linux/Solaris/OSX so that any blocked threads are interrupted. My
> guess is that if NativeThread.c is updated to define a signal on
> AIX they this should resolve some of the issues on AIX.
>
> I would like to see the list of tests failing. If there is an
> issue with dup2 with sockets (and OS X doesn't seem to have that
> issue) then it will require further work but I would at least
> like to start by understanding if this patch will help with the
> FileChannel issues.

Hi Alan,

yes, that's interesting. Sounds like a very similar problem on Mac.

I would suggest the following:

I cut out the "Async Close AIX FIX" stuff from this change (i.e.
"8031581: PPC64: Addons and fixes for AIX to pass the jdk regression
tests" and send out a new webrev for the remaining part. I think that
the remaining part was more or less reviewed and we can then push it
faster.

In the mean time, I'll recheck which tests exactly fail with my
missing "Async Close AIX FIX" stuff and which of these tests will be
fixed by your 7133499 webrev. Maybe we can really get trough with it
or with it and a few enhancements. I'll let you know my results later
today. By the way, my webrev already contained a AixNativeThread.c
implementation in src/aix/native/sun/nio/ch.

The only remaining problem I see with this approach is that we would
need to downport your 7133499 change to 8u-dev in the 8u20 time frame
to make our AIX port work. Would this be OK for you?

Regards,
Volker

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-20 Thread Alan Bateman


On 20/01/2014 09:59, Volker Simonis wrote:

:
Hi Alan,

yes, that's interesting. Sounds like a very similar problem on Mac.

I would suggest the following:

I cut out the "Async Close AIX FIX" stuff from this change (i.e.
"8031581: PPC64: Addons and fixes for AIX to pass the jdk regression
tests" and send out a new webrev for the remaining part. I think that
the remaining part was more or less reviewed and we can then push it
faster.

In the mean time, I'll recheck which tests exactly fail with my
missing "Async Close AIX FIX" stuff and which of these tests will be
fixed by your 7133499 webrev. Maybe we can really get trough with it
or with it and a few enhancements. I'll let you know my results later
today. By the way, my webrev already contained a AixNativeThread.c
implementation in src/aix/native/sun/nio/ch.

The only remaining problem I see with this approach is that we would
need to downport your 7133499 change to 8u-dev in the 8u20 time frame
to make our AIX port work. Would this be OK for you?

I'm okay with this plan and if you re-generate the webrev without the 
async close changes then I can look at it quickly so that you can get it 
into the stage-9 forest.


On 7133499 then it would be a good candidate for 8u-dev too, I don't 
expect any problems but we will need to get it approved on the jdk8u-dev 
list.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-20 Thread Volker Simonis

On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman  wrote:
> On 20/01/2014 09:59, Volker Simonis wrote:
>>
>> :
>> Hi Alan,
>>
>> yes, that's interesting. Sounds like a very similar problem on Mac.
>>
>> I would suggest the following:
>>
>> I cut out the "Async Close AIX FIX" stuff from this change (i.e.
>> "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression
>> tests" and send out a new webrev for the remaining part. I think that
>> the remaining part was more or less reviewed and we can then push it
>> faster.
>>
>> In the mean time, I'll recheck which tests exactly fail with my
>> missing "Async Close AIX FIX" stuff and which of these tests will be
>> fixed by your 7133499 webrev. Maybe we can really get trough with it
>> or with it and a few enhancements. I'll let you know my results later
>> today. By the way, my webrev already contained a AixNativeThread.c
>> implementation in src/aix/native/sun/nio/ch.
>>
>> The only remaining problem I see with this approach is that we would
>> need to downport your 7133499 change to 8u-dev in the 8u20 time frame
>> to make our AIX port work. Would this be OK for you?
>>
> I'm okay with this plan and if you re-generate the webrev without the async
> close changes then I can look at it quickly so that you can get it into the
> stage-9 forest.
>
> On 7133499 then it would be a good candidate for 8u-dev too, I don't expect
> any problems but we will need to get it approved on the jdk8u-dev list.
>
> -Alan.

Hi everybody,

so here's the second version of this webrev:

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

The main changes compared to the first webrew are as follows:

 - the POLL-constants related stuff has been factored out into its own
webrev ("8031997: PPC64: Make the various POLL constants system
dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997).
 - the "Async close on AIX" workarounds have been taken out as well
and will be handled separately (probably together with Alans fix for
http://cr.openjdk.java.net/~alanb/7133499/webrev/).

 - in the remaining files I've applied the changes suggested by
Staffan, so I think the changes to the following files can be
considered as reviewed:

src/share/native/sun/management/DiagnosticCommandImpl.c
src/solaris/native/sun/management/OperatingSystemImpl.c
src/share/transport/socket/socketTransport.c
src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider

 - I've added the following additional files to the change:

src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java
src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java

which are just empty stub implementations of the SCTP classes needed
to pass the SCTP jtreg tests.

All other changes should be the same like in the first review round.

Thanks,
Volker

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-20 Thread Alan Bateman


On 20/01/2014 13:45, Volker Simonis wrote:

:
Hi everybody,

so here's the second version of this webrev:

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

This looks okay to me.

The typo ("legel" -> "legal") still exists in zip_util.c and maybe that 
can be fixed before you push this (no need to generate a few webrev of 
course).


For the JDWP socket transport then it's interesting that shutdown is 
being used to cause the reader thread to be preempted. That may be 
useful when it comes to addressing the bigger async close issue.




The main changes compared to the first webrew are as follows:

  - the POLL-constants related stuff has been factored out into its own
webrev ("8031997: PPC64: Make the various POLL constants system
dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997).
I see this has been pushed to ppc-aix-port/stage-9. Would you have any 
objection if I brought this into jdk9/dev (minus the AixPollPort 
change)? We can use a different bug number so as not to cause duplicate 
bug issues. It should trivially merge when you come to sync'ing up the 
staging forest.




  - the "Async close on AIX" workarounds have been taken out as well
and will be handled separately
Thanks for separating this one out as I suspect this that doing this 
cleanly is going to involve changes for all platforms.


-Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-20 Thread Volker Simonis

On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman  wrote:
> On 20/01/2014 13:45, Volker Simonis wrote:
>>
>> :
>> Hi everybody,
>>
>> so here's the second version of this webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/
>
> This looks okay to me.

Thanks.

>
> The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can
> be fixed before you push this (no need to generate a few webrev of course).
>

Sorry, I've just fixed it in my patch queue and will used the fixed
version for pushing.

@Vladimir: could you please run this change
(http://cr.openjdk.java.net/~simonis/webrevs/8031581_2) through JPRT
as well. I'll push it (together with the fixed typo in the comment) if
everything is OK.

> For the JDWP socket transport then it's interesting that shutdown is being
> used to cause the reader thread to be preempted. That may be useful when it
> comes to addressing the bigger async close issue.
>
>
>>
>> The main changes compared to the first webrew are as follows:
>>
>>   - the POLL-constants related stuff has been factored out into its own
>> webrev ("8031997: PPC64: Make the various POLL constants system
>> dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997).
>
> I see this has been pushed to ppc-aix-port/stage-9. Would you have any
> objection if I brought this into jdk9/dev (minus the AixPollPort change)? We
> can use a different bug number so as not to cause duplicate bug issues. It
> should trivially merge when you come to sync'ing up the staging forest.
>

I have no objections of course. I'm just not sure what exact
implications this will have.

@Vladimir: what do you think - can Alan push "8031997: PPC64: Make the
various POLL constants system dependant" minus the Aix-specific stuff
to jdk9/dev now, without causing you any harm during integration.

@Alan: on the other hand, the bulk integration from
ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so
maybe you could wait until that happens?

Thanks,
Volker

>
>>   - the "Async close on AIX" workarounds have been taken out as well
>> and will be handled separately
>
> Thanks for separating this one out as I suspect this that doing this cleanly
> is going to involve changes for all platforms.
>
> -Alan.

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-20 Thread Alan Bateman


On 20/01/2014 16:29, Volker Simonis wrote:

:

@Alan: on the other hand, the bulk integration from
ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so
maybe you could wait until that happens?

In that case then ignore my request, I assumed it would not be pushed to 
jdk9/dev until end-Feb.


-Alan

RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

26 matches

Site Navigation

Mail list logo

Footer information