August 2015 - core-libs-dev

JDK 9 RFR of JDK-8133808: Place java/lang/ProcessHandle/InfoTest.java on the Problem List
by joe darcy 18 Aug '15

18 Aug '15

Hello, The test java/lang/ProcessHandle/InfoTest.java has been observed to fail intermittent and now with greater frequency on some system with the current HotSpot changes. While the underlying issues are being sorted out (JDK-8133552), it would be helpful to mark the test as intermittently failing and to place it on the problem list: diff -r 0940ce86c614 test/ProblemList.txt --- a/test/ProblemList.txt Thu Aug 13 21:46:05 2015 -0700 +++ b/test/ProblemList.txt Tue Aug 18 11:37:58 2015 -0700 @@ -129,6 +129,9 @@ # 8029891 java/lang/ClassLoader/deadlock/GetResource.java generic-all +# 8133552 +java/lang/ProcessHandle/InfoTest.java generic-all + ############################################################################ # jdk_instrument diff -r 0940ce86c614 test/java/lang/ProcessHandle/InfoTest.java --- a/test/java/lang/ProcessHandle/InfoTest.java Thu Aug 13 21:46:05 2015 -0700 +++ b/test/java/lang/ProcessHandle/InfoTest.java Tue Aug 18 11:37:58 2015 -0700 @@ -49,10 +49,12 @@ /* * @test + * @bug 8077350 8081566 8081567 8098852 * @build jdk.testlibrary.* * @library /lib/testlibrary * @summary Functions of ProcessHandle.Info * @author Roger Riggs + * @key intermittent */ public class InfoTest { Thanks, -Joe

2 1

RFR [9] 8132478: [tidy] three new warnings from java docs (java.net, javax.annotation)
by Alexander Stepanov 18 Aug '15

18 Aug '15

Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8132478/jdk.00/index.html http://cr.openjdk.java.net/~avstepan/8132478/jaxws.00/index.html for https://bugs.openjdk.java.net/browse/JDK-8132478 Just a minor fix for docs (a few tidy warnings + some invalid tags). Thanks, Alexander

2 2

Possible long overflow in Collectors.averagingLong and LongStream.average
by Tagir F. Valeev 15 Aug '15

15 Aug '15

Hello! The following code prints -1 twice, while users would normally expect something like 9.223372036854776E18: double avg1 = Stream.of(Long.MAX_VALUE, Long.MAX_VALUE).collect( Collectors.averagingLong(Long::valueOf)); System.out.println(avg1); double avg2 = LongStream.of(Long.MAX_VALUE, Long.MAX_VALUE).average() .getAsDouble(); System.out.println(avg2); That's because in both cases internally sum is calculated in the long variable where it may silently overflow. The documentation for both methods says nothing about such possibility. I guess if it's too late to fix this behavior, then probably it should be at least properly documented? With best regards, Tagir Valeev.

1 1

[9] RFR: 8060717: [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments()
by Konstantin Shefov 14 Aug '15

14 Aug '15

Hello, Please review a test improvement. Covered more cases for MethodHandles.explicitCastArguments(). Bug: https://bugs.openjdk.java.net/browse/JDK-8060717 Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/ -Konstantin

3 9

[9] RFR: 8133543: [TESTBUG] java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java should be modified
by Konstantin Shefov 14 Aug '15

14 Aug '15

Hello, Please review a test bug fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8133543 Webrev: http://cr.openjdk.java.net/~kshefov/8133543/webrev.00/ -Konstantin

3 2

Fwd: Re: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add implememtation for AIX
by Roger Riggs 14 Aug '15

14 Aug '15

Hi Volker, Thanks for the refactoring and the AIX implementation. We still need a tie-breaker with respect to the issue of truncated/incomplete argument and executable values. On 7/24/2015 9:30 AM, Volker Simonis wrote: > Hi, > > so here comes the new webrev which cleanly applies to the current > jdk9-dev/jdk repo: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v2/ Comments: os_getParentPid() - the function name doesn't reflect the additional values returned. The time units on the starttime and cputime need should appear in the function header without having to refer to the declaration. os_getParentPid() - Within this function can the code that accesses the sysctl info be kept together. Perhaps move the rusage if/block before the if (sysctl) {...} Or just move the start time extraction to just before the return pid.. ProcessHandleImpl_unix.c: 138 and 140 - The macros should not include the trailing semicolon ";" (causes a unreachable compilation warning on Solaris 10) ProcessHandlmpl_unix.c: 401: extra semicolon ";;" (causes a warning about declarations after statements on Solaris 10). 691: Typo: Solris 730: separeted ProcessHandleImpl_unix:c: 358 - Info_info0 - it appears that the psinfo file is read twice. Once by unix_getUid and again by unix_getCmdLineInfo One aspect of the original code was to avoid opening and reading /proc files more than once/necessary. ProcessHandleImpl_unix.c: 691-700 - There is no point in doing a file lookup that is known to fail. This should be #ifdef/#ifndef'd to apply only to the appropriate OS. !! ProcessHandleImpl_unix: 709-738: I still disagree with returning truncated or incomplete values for the executable or arguments. Can anyone be a tie-breaker (with a good rational and suggestion for how an application can use the data). InfoTest.java: 139: Is this the best that can be done for checking the times on AIX? InfoTest.java:285 - mentions /proc/pid/status ; should that be /proc/pid/psinfo? ProcessHandleImpl_linux.c: 63: getUID and getCmdlineInfo both format the /proc file name and do a lookup of the file. The original version avoided doing the lookup twice in the same native call. Perhaps there is a refactoring that puts the extraction of the UID in with getting the command line. This might address the repeated reading of psinfo in ProcessHandleImpl_unix:358 as well. ProcessHandleImpl_unix.h is a new file and only needs a 2015 copyright date. Somewhere the unixs for the start and cputimes needs to be documented at the declaration. That is first pass on comments. Thanks, Roger > The good thing beforehand - although I added the AIX-port and a big > 50-line comment the new version is still 60 lines shorter :) > 10 files changed, 829 insertions(+), 999 deletions(-) > > The main idea behind the new code layout is as follows (see the > comment in ProcessHandleImpl_unix.c for more details): > > The currently supported Unix variants are Solaris, Linux, MaxOS X > and AIX. The various similarities and differences between these > systems make it hard to find a clear boundary between platform > specific and shared code. > > In order to ease code sharing between the platforms while still > keeping the code as clean as possible (i.e. free of preprocessor > macros) we use the following source code layout (remember that > ProcessHandleImpl_unix.c will be compiled on EVERY Unix platform > while ProcessHandleImpl_<os>.c will be only compiled on the > specific OS): > > - all the JNI wrappers for the ProcessHandleImpl functions go > into ProcessHandleImpl_unix.c file > > - if their implementation is common on ALL the supported Unix > platforms it goes right into the JNI wrappers > > - if the whole function or substantial parts of it are platform > dependent, the implementation goes into os_<function_name> > functions in ProcessHandleImpl_<os>.c > > - if at least two platforms implement an os_<function_name> > function in the same way, this implementation is factored out > into unix_<function_name>, placed into > ProcessHandleImpl_unix.c and called from the corresponding > os_<function_name> function. > > - For convenience, all the os_ and unix_ functions are declared > in ProcessHandleImpl_unix.h which is included into every > ProcessHandleImpl_<os>.c file. > > So ProcessHandleImpl_unix.c only contains code which is shared by at > least two platforms. Code which is specific to one single platform > goes into the corresponding ProcessHandleImpl_<os>.c file (and this > changes adds ProcessHandleImpl_aix.c for AIX-specific code and > ProcessHandleImpl_linux.c for Linux-specific code which was in > ProcessHandleImpl_unix.c previously). > > I tried to unify similar functions (e.g. > Java_java_lang_ProcessHandleImpl_00024Info_initIDs, > Java_java_lang_ProcessHandleImpl_isAlive0 or fillArgArray) into a > single instance in ProcessHandleImpl_unix.c. > > I renamed and unified getStatInfo() into > os_getParentPid()/unix_getParentPid() with three implemantions for > MacOSX, Linux and Solaris/AIX. > > I've factored out Java_java_lang_ProcessHandleImpl_getProcessPids0() > into os_getChildren()/unix_getChildren() with two implemantions - one > for MacOSX and one for Linux/Solaris/AIX. > > I've tested the new implementation on MacOSX, Linux (x86_64 and ppc64) > , Solaris 10/11 (x86_64 and Sparc) and AIX. > > The final point, which was already mentioned in the first review is > the fact that we can not easily get accurate information fort he > command line and arguments on AIX. I'd prefer to stay with the current > solution which gives "best effort" answers for these attributes but if > everybody’s opinion is that such information is useless I can also > omit it altogether. I haven’t looked at the other platforms which we > have to support (e.g. HPUX, AS/400) but the situation may be similar > there. > > Regards, > Volker >

3 17

RFR [9] 8133480: replace some <tt> tags (obsolete in html5) in core-libs docs
by Alexander Stepanov 14 Aug '15

14 Aug '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133480/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8133480 Just another portion of deprecated <tt> tags replaced with {@code }. A single misprint was fixed; no other changes indicated by specdiff. Thanks, Alexander

2 2

JDK 9 RFR of JDK-8133588: Place TimeoutLockLoops.java on the problem lis
by joe darcy 14 Aug '15

14 Aug '15

Hello, Until a fix for JDK-8029453 is in place, the test TimeoutLockLoops.java should be placed on the problem list for Linux since it fails intermittently, but fairly frequently, on that OS: --- a/test/ProblemList.txt Thu Aug 13 09:36:14 2015 -0700 +++ b/test/ProblemList.txt Thu Aug 13 14:14:39 2015 -0700 @@ -353,6 +353,10 @@ # 8062512 java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java generic-all +# 8029453 +java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java linux-all + + ############################################################################ # jdk_instrument Thanks, -Joe

3 3

[9] RFR: 8133321: (tz) Support tzdata2015f
by Aleksej Efimov 13 Aug '15

13 Aug '15

Hello, Please review latest tzdata (2015f) integration into JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00 Testing shows no TZ related failures on all platforms. Thanks, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8133321

2 1

JDK 9 RFR of JDK-8079769: tools/pack200/PackTestZip64.java may timeout at preparing the large test file
by Amy Lu 12 Aug '15

12 Aug '15

Please review the fix for test issue: tools/pack200/PackTestZip64.java may timeout at preparing the large test file This test tries to create a big jar file for testing by adding a large number (Short.MAX_VALUE * 2 + 2) of small files to the golden jar (golden.jar). This prepare work is i/o sensitive and may take long thus may timeout (depending on the run timeout settings), especially when many tests run in concurrency. To make the test more stable, without losing test coverage, this fix makes: * PackTestZip64.java tests on the golden.jar only * PackTestZip64Manual.java still tests on the big jar bug: https://bugs.openjdk.java.net/browse/JDK-8079769 webrev: http://cr.openjdk.java.net/~amlu/8079769/webrev.00/ Thanks, Amy

2 1