On 15/01/2014 12:10 AM, Volker Simonis wrote:
On Tue, Jan 14, 2014 at 12:29 PM, David Holmes <david.hol...@oracle.com
<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 <http://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/
<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
<http://www.java.net/download/jdk8/testresults/testresults.html>
<http://www.java.net/download/__jdk8/testresults/testresults.__html
<http://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
<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
<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()| and the |NET_|
prefix is probably not appropriate any more so maybe change
it to
something like |IO_|). But again, I'll prefer to keep that as a
follow up change for JDK9.
* Calling |fsync()| on a "read-only" file descriptor on AIX will
result in an error (i.e. "EBADF: The FileDescriptor
parameter is not
a valid file descriptor open for writing."). To prevent
this error
we have to query if the corresponding file descriptor is
writeable.
Notice that at that point we can not access the |writable|
attribute
of the corresponding file channel so we have to use |fcntl()|.
src/solaris/classes/java/lang/__UNIXProcess.java.aix
* On AIX the implementation is especially tricky, because the
|close()| system call will block if another thread is at
the same
time blocked in a file operation (e.g. 'read()') on the
same file
descriptor. We therefore combine the AIX
|ProcessPipeInputStream|
implemenatation with the |DeferredCloseInputStream|
approach used on
Solaris (see |UNIXProcess.java.solaris|). This means that every
potentially blocking operation on the file descriptor
increments a
counter before it is executed and decrements it once it
finishes.
The 'close()' operation will only be executed if there are no
pending operations. Otherwise it is deferred after the last
pending
operation has finished.
src/share/transport/socket/__socketTransport.c
* On AIX we have to call |shutdown()| on a socket descriptor
before
closing it, otherwise the |close()| call may be blocked.
This is the
same problem as described before. Unfortunately the JDI
framework
doesn't use the same IO wrappers like other class library
components
so we can not easily use the |NET_| abstractions from
|aix_close.c|
here.
* Without this small change all JDI regression tests will
fail on AIX
because of the way how the tests act as a "debugger" which
launches
another VM (the "debugge") which connects itself back to the
debugger. In this scenario the "debugge" can not shut down
itself
because one thread will always be blocked in the |close()|
call on
one of the communication sockets.
src/solaris/native/java/net/__NetworkInterface.c
* Set the scope identifier for IPv6 addresses on AIX.
src/solaris/native/java/net/__net_util_md.c
* It turns out that we do not always have to replace
|SO_REUSEADDR| on
AIX by |SO_REUSEPORT|. Instead we can simply use the same
approach
like BSD and only use |SO_REUSEPORT| additionally, if several
datagram sockets try to bind to the same port.
* Also fixed a comment and removed unused local variables.
* Fixed the obviously inverted assignment |newTime =
prevTime;| which
should read |prevTime = newTime;|. Otherwise |prevTime|
will never
change and the timeout will be potential reached too fast.
src/solaris/native/sun/__management/__OperatingSystemImpl.c
* AIX does not understand |/proc/self| so we have to query
the real
process ID to access the proc file system.
src/solaris/native/sun/nio/ch/__DatagramChannelImpl.c
* On AIX, |connect()| may legally return |EAFNOSUPPORT| if
called on a
socket with the address family set to |AF_UNSPEC|.
