February 2014 - core-libs-dev

RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat
by Ivan Gerasimov 20 Mar '14

20 Mar '14

Hello! We've got one quite old report about been unable to run the test under Android. https://bugs.openjdk.java.net/browse/JDK-6943190 That was due to hard-coded path to the cat utility as /bin/cat. When investigating, I found two other tests under the same directory that use /usr/bin/cat and /usr/bin/echo. These two test seem to (almost) never run because of the unusual path. Here's the first version of the webrev, with the fix to only three tests mentioned above: http://cr.openjdk.java.net/~igerasim/6943190/0/webrev/ java/lang/Runtime/exec/ directory has also got several other tests, which run shell commands. Some of them have absolute path and some of them don't. So I have a general question: Why would we ever need the absolute path for the commands? Why wouldn't we rely on the PATH env variable? Sincerely yours, Ivan

4 22

Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods
by Paul Sandoz 13 Mar '14

13 Mar '14

Hi, Out of all the methods on Unsafe i think the monitorEnter/monitorExit/tryMonitorEnter are the least used and are very strong candidates for removal. 99% of use-cases are supported by classes in the java.util.concurrent.locks package. Within the JDK itself it is only used in one JDK test file test/java/lang/ProcessBuilder/Basic.java: while (unsafe.tryMonitorEnter(s)) { unsafe.monitorExit(s); Thread.sleep(1); } for a test verifying an EOF is received on pending reads and it is polling to check when the process builder acquires the lock before destroying the process, presumably to avoid some sort of race condition that occasionally causes the test to fail. I believe this test as been through a number of rounds, i stared at things for a bit, but cannot quickly work out a replacement; i lack the knowledge on this area. Outside of the JDK i can only find one usage of monitorExit/Enter (according to grep code) in JBoss modules, and i believe this is only used on Java 1.6 to work around some limitations in class loading that were fixed in 1.7. Given such very limited use i propose to remove these methods after having worked out a fix for ProcessBuilder/Basic.java test. Paul.

13 38

Unsafe: efficiently comparing two byte arrays
by Paul Sandoz 13 Mar '14

13 Mar '14

Hi, A common reason why Unsafe is used is to more efficiently compare two unsigned byte arrays, viewing those byte arrays as long arrays. See Guava [1] and a number of apache frameworks for similar code. One solution is to provide such functionality in Arrays for all primitives and probably refs [2]: int Arrays.compare(byte[], byte[]); Then it is easy to create a comparator using a method reference: Comparator<byte[]> c = Arrays::compare; There could, initially, be Java implementations for those methods, including using Unsafe for byte[]. I gather those methods could be intrinsified to implementations using SIMD instructions on supported platforms. I don't know if that is possible today with Hotspot, but regardless i think a good start would be to have Java-based implementations in place. Thoughts? Paul. [1] http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/pr… [2] https://bugs.openjdk.java.net/browse/JDK-8033148

7 22

RFR: 7152892: some jtreg tests fail with permission denied
by Rob McKenna 07 Mar '14

07 Mar '14

Hi folks, When files are copied by our test harness the permissions are left unchanged. This can cause trouble for a few tests when the test folder is read only. http://cr.openjdk.java.net/~robm/7152892/webrev.01/ -Rob

4 5

[7u backport] RFR: 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations
by dmeetry degrave 06 Mar '14

06 Mar '14

Hi all, I would like to ask for a review of combined back port for 7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it also integrates the changes from 8005232, 7185456, 8022721 https://bugs.openjdk.java.net/browse/JDK-7122142 https://bugs.openjdk.java.net/browse/JDK-8005232 https://bugs.openjdk.java.net/browse/JDK-7185456 https://bugs.openjdk.java.net/browse/JDK-8022721 Original jdk8 changes: 7122142: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0 8005232: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 7185456: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 8022721: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738 back port: http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.… Patches can't be applied cleanly, hence it was a manual back port, though the final result is equivalent to applying the patches in chronological order (8005232, 7185456, 7122142, 8022721) and applying all the relevant rejected parts (with one exception, AnnotationTypeRuntimeAssumptionTest.java test was not included due to jdk8 API). All tests in test/java/lang/annotation passed. thanks, dmeetry

4 5

JDK 9 RFR of JDK-8035452: Fix serial lint warnings in core libs
by Joe Darcy 05 Mar '14

05 Mar '14

Hello, Please review the patch below which will address the handful of remaining serial lint warning in the core libraries. Thanks, -Joe diff -r e5a09bc70308 src/share/classes/java/util/EnumSet.java --- a/src/share/classes/java/util/EnumSet.java Thu Feb 20 13:03:36 2014 +0000 +++ b/src/share/classes/java/util/EnumSet.java Thu Feb 20 12:32:52 2014 -0800 @@ -80,6 +80,8 @@ public abstract class EnumSet<E extends Enum<E>> extends AbstractSet<E> implements Cloneable, java.io.Serializable { + private static final long serialVersionUID = 1009687484059888093L; + /** * The class of all the elements of this set. */ diff -r e5a09bc70308 src/share/classes/java/util/TreeMap.java --- a/src/share/classes/java/util/TreeMap.java Thu Feb 20 13:03:36 2014 +0000 +++ b/src/share/classes/java/util/TreeMap.java Thu Feb 20 12:32:52 2014 -0800 @@ -1333,6 +1333,7 @@ /** * @serial include */ + @SuppressWarnings("serial") // Abstract class abstract static class NavigableSubMap<K,V> extends AbstractMap<K,V> implements NavigableMap<K,V>, java.io.Serializable { /** diff -r e5a09bc70308 src/share/classes/sun/reflect/annotation/ExceptionProxy.java --- a/src/share/classes/sun/reflect/annotation/ExceptionProxy.java Thu Feb 20 13:03:36 2014 +0000 +++ b/src/share/classes/sun/reflect/annotation/ExceptionProxy.java Thu Feb 20 12:33:21 2014 -0800 @@ -37,5 +37,6 @@ * @since 1.5 */ public abstract class ExceptionProxy implements java.io.Serializable { + private static final long serialVersionUID = 7241930048386631401L; protected abstract RuntimeException generateException(); }

4 9

JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger
by Brian Burkhalter 04 Mar '14

04 Mar '14

This patch concerns cleaning up some ugly internal deprecations. Issue: https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev: http://cr.openjdk.java.net/~bpb/8035279/webrev.00/ All JTREG BigInteger tests pass, and the serialized form has been unaltered as verified by bidirectional read-write testing between Java 7 and this version. I would appreciate scrutiny of the arithmetic to make sure that I've made no silly errors. Also I would be interested in opinions as to whether the "volatile" keyword should in fact be used for the affected instance variables. Thank you for your comments. Brian

9 49

RFR (JAXP): 8035469 : Xerces Update: EncodingMap does not recognise Java-style encodings Cp1141-Cp1149
by David Li 03 Mar '14

03 Mar '14

Hi, This is an update from Xerces for a fixed encoding map entry in file EncodingMap.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035469 Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035469/webrev/ (I don't have a openjdk username yet, so Joe Wang uploaded it) No new tests since the change is minor. There were no tests from Apache fixes. Thanks, David

4 5

[9] RFR (M): 8027827: Improve performance of catchException combinator
by Vladimir Ivanov 03 Mar '14

03 Mar '14

http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.00 https://jbs.oracle.com/bugs/browse/JDK-8027827 354 lines changed: 193 ins; 91 del; 70 mod OVERVIEW MethodHandles.catchException combinator implementation is based on generic invokers (MethodHandleImpl$GuardWithCatch.invoke_*). It is significantly slower than a Java equivalent (try-catch). Future Nashorn performance improvements require catchException combinator speed to be on par with try-catch in Java. So, it should be represented in a more efficient form. I chose the following lambda form representation: t_{i}:L=ValueConversions.array(a1:L,...,a_{k}:L); t_{i+1}:L=MethodHandleImpl.guardWithCatch(t_{p1}, t_{p2}, t_{p3}, t_{i}:L); t_{i+2}:I=ValueConversions.unbox(t7:L); OR :L=ValueConversions.identity(t_{n+1}) OR :V=ValueConversions.ignore(t_{n+1}) where: a1, ..., a_{k} - arguments t_{p1}, t_{p2}, t_{p3} - target method handle, exception class, catcher method handle respectively; passed as bounded parameters; During lambda form compilation it is converted into bytecode equivalent of the following Java code: try { return target.invokeBasic(...); } catch(Throwable e) { if (!exClass.isInstance(e)) throw e; return catcher.invokeBasic(e, ...); } There's a set of microbenchmarks (attached to the bug) I wrote to verify performance characteristics of new implementation. FURTHER WORK What is missing is lambda form caching. The plan is to have a single lambda form per basic type, but it needs more work - current representation is suitable for sharing on bytecode level, but lambda form interpretation doesn't work well (arguments boxing + result unboxing are problematic). TESTING Tests: microbenchmarks, jdk/java/lang/invoke/, nashorn with optimistic types (unit tests, octane). Tested in 2 modes: * COMPILE_THRESHOLD=30 * COMPILE_THRESHOLD=0 -Xverify:all OTHER 1) Update of cached name and member in LF compilation loop (see InvokerBytecodeGenerator.generateCustomizedCodeBytes) fixes a bug during compilation of selectAlternative when running with COMPILE_THRESHOLD=0. 2) As part of this change, I fix existing bug [1], so I add regression test for it. Thanks! Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8034120

6 15

Signature of MethodHandleInfo.reflectAs is not specific enough
by Remi Forax 01 Mar '14

01 Mar '14

The is a stupid issue with the signature of MethodHandleInfo.reflectAs, j.l.r.Field, Method or Constructor implement two interfaces Member and AnnotatedElement, with the current signature, the code info.reflectAs(Member.class, lookup) works but the code info.reflectAs(AnnotatedElement.class, lookup) doesn't work. Because there is no way to do an 'or' between several bounds of a type variable, I think that the signature of reflectAs should be changed from : public <T extends Member> T reflectAs(Class<T> expected, Lookup lookup); to public <T> T reflectAs(Class<T> expected, Lookup lookup); and the javadoc should be modified to explain that a Member or AnnotatedElement are valid bounds of T. As a side effect, the signature of MethodHandles.reflectAs(Class<T>, MethodHandle) should be updated accordingly. There is a workaround, one can write: (AnnotatedElement)info.reflectAs(Member.class, lookup) but it's at best weird. cheers, Rémi

5 8