June 2015 - core-libs-dev

RFR: JDK-8080225: FileInputStream cleanup should be improved
by Peter Levart 30 Jun '15

30 Jun '15

Hi, As part of JEP 132 (More-prompt finalization) I wanted to find out what it would take to convert finalization-based cleanup code used in a JDK class to PhantomReference-based. In FileInputStream case, the state needed for clean-up is stored in a FileDescriptor referenced from FileInputStream. To make things complicated, FileDescriptor instance can be shared among FileInputStream(s), FileOutputStream(s) and/or RandomAccessFile(s). Shared FileDescriptor instance keeps track (using strong references) of any FileInputStream, FileOutputStream or RandomAccessFile it is registered with (FileDescriptor.attach(Closeable)). A graph of FileInputStream(s), FileOutputStream(s) and/or RandomAccessFile(s) sharing a FileDescriptor is therefore strongly connected in all directions. FileInputStream and FileOutputStream override finalize() method, RandomAccessFile doesn't. When all FileInputStream(s), FileOutputStream(s) and/or RandomAccessFile(s) connected together with the shared FileDescriptor become eligible for finalization, finalize() methods of FileInputStream(s) and FileOutputStream(s) get called. They delegate to stream close() method(s) in turn which delegate to FileDescriptor.closeAll() which close()s all streams sharing the FileDescriptor and finally calls-back into the 1st stream which invoked closeAll() to close the FileDescriptor (via the call to native [FileInputStream|FileOutputStream|RandomAccessFile].close0() method). To untangle this knot, I had to refactor some internal logic: http://cr.openjdk.java.net/~plevart/jdk9-dev/8080225_FileStreamCleanUp/webr… Since all native [FileInputStream|FileOutputStream|RandomAccessFile].close0() methods do the same thing with FileDescriptor, I moved the method to FileDescriptor and made it static while adding an int fd (UNIX) / long handle (Windows) parameter. Clean-up action invokes this method when all connected stream(s) and FileHandle objects are already gone. The clean-up thunk is registered in initFd (UNIX) / initHandle (Windows) method invoked from JNI code of FileInputStream, FileOutputStream or RandomAccessFile (see modified SET_FD macro in io_util_md.h). Clean-up registration therefore only happens for FileInputStream, FileOutputStream and RandomAccessFile (the later therefore gets automatic cleanup which was not present before). All other usages of FileDescriptor throughout JDK don't register cleanup and therefore behave unchanged. all java/io jtreg tests pass except of course the following two: JT Harness : Tests that failed java/io/FileInputStream/FinalizeShdCallClose.java: Test to ensure that FIS.finalize() invokes the close() method as per the specification. java/io/FileOutputStream/FinalizeShdCallClose.java: Test to ensure that FOS.finalize() invokes the close() method as per the specification. They don't even compile, since the removal of overriding File[Input|Output]Stream.finalize() method which throws IOException exposes Object.finalize() which throws Throwable. The tests override File[Input|Output]Stream classes and finalize() methods, calling super.close(). This change is therefore not entirely source-compatible, but removing finalization from the File streams can not be performed without the removal of the finalize() methods, so if this is the direction to be taken, such source-incompatibility has to be taken into account. I don't belive there are many File stream subclasses that override finalize() and call super.finalize(). Wait a second, there are two in JDK itself (Socket[Input|Output]Stream), but they override finalize() to "disable" finalization - making it a no-op. Removing both overrides therefore removes no-op finalization from Socket streams too... The presented patch uses sun.misc.Cleaner for demonstration purposes only. I don't know if it's use in this scenario is correct since closing the file can be a blocking operation and Cleaner(s) are executed by ReferenceHandler thread. I think a PhantomCleaner presented in my proposal for JEP-132 which is executed by same thread(s) as finalizers is more suitable for this purpose. So, what do you think? Is this the direction to evolve File stream automatic clean-up to? Regards, Peter

1 0

RFR: 8050091: LinkedList has incorrect implementation comment
by Martin Buchholz 30 Jun '15

30 Jun '15

Hi Ivan, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8050091 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/LinkedList-invariant/

3 7

Re: RFR(S): 6896810:TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println
by David Holmes 30 Jun '15

30 Jun '15

cc'ing core-libs-dev as they own this test. On 30/06/2015 10:54 PM, Stefan Särne wrote: > > Hi all, > > Please review and sponsor this fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6896810 > <https://bugs.openjdk.java.net/browse/JDK-8073718>Webrev: > http://cr.openjdk.java.net/~sjohanss/sponsor/ssarne/JDK-6896810/webrev.jdk.… > > <http://cr.openjdk.java.net/%7Esla/stefan/8073718/webrev.00/> > The test fails since it run out of memory (again) when it tries to print > that the expected OOME is received. Additional allocations are done > during printing and the next OOME is thrown out of the test. By freeing > the "chain" that hogs the memory on the heap, the test continues and the > additional checks of checking that the blocks are empty are performed > and pass. Seems a reasonable approach to free up the memory - or at least allow a GC to reclaim it. David ----- > Tested: Run with all GC combinations. > > The test is part of tier1 for the jdk and this blocks integration from > jdk9/hs to jdk9/dev and I therefore suggest it is integrated directly to > jdk9/hs. > > Thanks, > Stefan

2 1

Review request: JDK-8080108: [TEST_BUG] The case failed automatically and thrown java.lang.RuntimeException
by Alexander Fomin 30 Jun '15

30 Jun '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8080108 webrev attached. Either you can see it by the link http://stt-13.ru.oracle.com/newroot/tmp/alex/regression/JDK-8080108/JDK9/de… The original test (com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580) fails automatically if /etc/resolv.conf file doesn't contain IPv6 nameserver entries. As far as we can't rely on "sudo" during regression tests execution we have to manually edit /etc/resolv.conf before the test run. The test has to be run on non-Windows systems only. Fix: provided standard test machinery for regression manual tests with instructions for a user; the test excluded for Windows. Tested on Linux and Windows(to make sure it's excluded) with jtreg 4.2. Thanks, Alexander

1 2

RFR: 8130051 Cleanup usage of reflection in jaxp
by Daniel Fuchs 30 Jun '15

30 Jun '15

Hi, Please find below a patch that cleans up some of the reflection usage in jaxp. https://bugs.openjdk.java.net/browse/JDK-8130051 http://cr.openjdk.java.net/~dfuchs/webrev_8130051/webrev.00/ This is not a deep cleanup - it is just a first pass... There may be some opportunity to get rid of some more obsolete code - which can be addressed by followup bugs/RFE (such as JDK-8129892). I also took this opportunity to remove two files which are not used in the JDK. jaxp/test, jdk/test/javax/xml/jaxp, and JCK test suites (api/javax_xml api/xinclude api/xsl xml_schema) passed. best regards, -- daniel

2 3

RFR - 8129956: jaxp: CodeSource.getLocation() might return null
by Daniel Fuchs 30 Jun '15

30 Jun '15

Hi, It was brought to my attention that CodeSource.getLocation() might return null. The javadoc is not very clear on the subject, leading me to believe it could not. Here is a trivial change (with some trivial additional cleanup) that adds guards against null before calling getLocation().toString(); http://cr.openjdk.java.net/~dfuchs/webrev_8129956/webrev.00/ best regards, -- daniel

6 14

RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles
by Ivan Gerasimov 30 Jun '15

30 Jun '15

Hello! This test fails when running on compact1 and compact2, since it tries to access all the jars from "sun.boot.class.path". The easiest approach would be to include it in the group, which requires at least compact3. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080524 WEBREV: http://cr.openjdk.java.net/~igerasim/8080524/00/webrev/ Sincerely yours, Ivan

4 9

RFR 8080640: Reduce copying when reading JAR/ZIP entries
by Staffan Friberg 29 Jun '15

29 Jun '15

Hi, Wanted to get reviews and feedback on this performance improvement for reading from JAR/ZIP files during classloading by reducing unnecessary copying and reading the entry in one go instead of in small portions. This shows a significant improvement when reading a single entry and for a large application with 10k classes and 500+ JAR files it improved the startup time by 4%. For more details on the background and performance results please see the RFE entry. RFE - https://bugs.openjdk.java.net/browse/JDK-8080640 WEBREV - http://cr.openjdk.java.net/~sfriberg/JDK-8080640/webrev.0 Cheers, Staffan

2 15

[9] RFR of 8042983: test/java/math/BigInteger/ExtremeShiftingTests.java needs too much heap
by Brian Burkhalter 29 Jun '15

29 Jun '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8042983 Patch: see diff below Summary: Restrict test execution to systems having at least 1GB of physical memory. Thanks, Brian --- a/test/java/math/BigInteger/ExtremeShiftingTests.java +++ b/test/java/math/BigInteger/ExtremeShiftingTests.java @@ -25,6 +25,7 @@ * @test * @bug 6371401 * @summary Tests of shiftLeft and shiftRight on Integer.MIN_VALUE + * @requires os.maxMemory >= 1g * @run main/othervm -Xmx512m ExtremeShiftingTests * @author Joseph D. Darcy */

2 1

RFR: 8076139: [TEST_BUG] test/javax/xml/ws/8046817/GenerateEnumSchema.java creates files in test.src
by Aleksej Efimov 28 Jun '15

28 Jun '15

Hi, Please, review, comment and approve GenerateEnumSchema.java test bug fix [1]. It solves the following problem: test launches schemagen tool from a 'test.src' folder and in cases when 'test.src' is not writeable failure occurs. The proposed fix [2] solves this issue - it creates a test folder in a scratch (or in current) directory and also populates directories for each schemagen run (output for each run is saved for analysis). Modified test was executed via JPRT and JTREG. In case of JTREG it was executed over read-only 'test.src' directory too. No test failure were observed. Also, the test was moved to proper directory (test/javax/xml/bind/jxc/8046817) to match it's nature and functionality. With Best Regards, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8076139 [2] Webrev: http://cr.openjdk.java.net/~aefimov/8076139/9/00

2 5