June 2015 - core-libs-dev

Review request for JDK-8080907 - Develop test for Xerces Update: XML Schema Validation
by Frank Yuan 12 Jun '15

12 Jun '15

Hi Joe, Lance and all Would you like to have a review for bug: https://bugs.openjdk.java.net/browse/JDK-8080907? I added some new tests and updated some existing tests to add more coverage for JAXP library. The webrev is at http://cr.openjdk.java.net/~fyuan/8080907/webrev.00/, your comment will be appreciated. Best Regards Frank

3 2

[9] RFR of 8087288: File.get{Free, Total, Usable}Space may return unexpected results with >2TB file systems
by Brian Burkhalter 12 Jun '15

12 Jun '15

Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8087288 Patch: http://cr.openjdk.java.net/~bpb/8087288/webrev.00/ The root cause of this problem is essentially the same as that of https://bugs.openjdk.java.net/browse/JDK-8081843 and the proposed fix is likewise similar: on Mac OS X replace statvfs64() and struct statvfs64 with statfs() and struct statfs, respectively, and f_frsize with f_bsize. Thanks, Brian

2 1

RFR: 8087283 : Add support for the XML Signature here() function to the JDK XPath implementation
by Sean Mullan 12 Jun '15

12 Jun '15

Please review this change to add support for the XML Signature here() function to the JDK XPath implementation. The here function is not defined in its own namespace. Therefore it needs to be implemented by extending the function library of XPath in the same namespace. Currently, the JDK XML Signature implementation uses reflection to invoke a method of an implementation-specific class in the JDK XPath library to register the here function. This fix provides a much cleaner solution that avoids use of reflection by extending the built-in set of XPath functions to include the here function. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8087283/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8087283 Thanks, Sean

3 2

RFR(XS): 8081412: Remove MHIllegalAccess.java from the problem list
by Andreas Eriksson 12 Jun '15

12 Jun '15

Hi, Id like to remove java/lang/invoke/8022701/MHIllegalAccess.java from the problem list. It was added while the test fix propagated to the correct repos. [1] Now the fix has propagated. [2] Change, generated by running hg backout: diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -123,9 +123,6 @@ # 8029891 java/lang/ClassLoader/deadlock/GetResource.java generic-all -# 8080428 -java/lang/invoke/8022701/MHIllegalAccess.java generic-all - ############################################################################ # jdk_instrument Thanks, Andreas [1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033760.html [2]: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8cad1a9fee4a

2 1

RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset
by Volker Simonis 11 Jun '15

11 Jun '15

Hi, can I please have review (and a sponsor) for these changes: https://bugs.openjdk.java.net/browse/JDK-8081674 http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs Please notice that the fix requires synchronous changes in the jdk and the hotspot forest. The changes themselves are by far not that big as this explanation but I found the problem to be quite intricate so I tried to explain it as good as I could. I'd suggest to read the HTML-formatted explanation in the webrev although the content is equal to the one in this mail: Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) results in an immediate VM failure with jdk 8 and 9: export LANG=vi_VN.TCVN java -version Error occurred during initialization of VM java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at java.lang.System.initializeSystemClass(System.java:1194) This is a consequence of "8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs". With jdk 9 we get this error even if we're running with a supported charset which is in the ExtendedCharsets (as opposed to being in the StandardCharsets) class which is a consequence of delegating the loading of the ExtendedCharsets class to the ServiceLoader in jdk 9. export LANG=eo.iso-8859-3 output-jdk9/images/jdk/bin/java -version Error occurred during initialization of VM java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) at java.lang.Runtime.loadLibrary0(Runtime.java:874) at java.lang.System.loadLibrary(System.java:1111) at java.lang.System.initializeSystemClass(System.java:1186) Here's why the exception happens for an unsupported charset (see the mixed stack trace below for the full details): java.lang.System.loadLibrary() wants to load libzip.so. It calls java.lang.Runtime.loadLibrary0() which at the very beginning calls the native method ClassLoader$NativeLibrary.findBuiltinLib() which checks if the corresponding library is already statically linked into the VM (introduced by 8005716). Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), the native implementation of findBuiltinLib() in Classloader.c calls GetStringPlatformChars() to convert the library name into the native platform encoding. GetStringPlatformChars() calls the helper function jnuEncodingSupported() to check if the platform encoding which is stored in the property "sun.jnu.encoding" is supported by Java. jnuEncodingSupported() is implemented as follows: static jboolean isJNUEncodingSupported = JNI_FALSE; static jboolean jnuEncodingSupported(JNIEnv *env) { jboolean exe; if (isJNUEncodingSupported == JNI_TRUE) { return JNI_TRUE; } isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( env, &exe, "java/nio/charset/Charset", "isSupported", "(Ljava/lang/String;)Z", jnuEncoding).z; return isJNUEncodingSupported; } Once the function finds that the platform encoding is supported (by calling java.nio.charset.Charset.isSupported()) it caches this value and always returns it on following calls. However if the platform encoding is not supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an every subsequent invocation. In order to call the Java method Charset.isSupported() (in JNU_CallStaticMethodByName() in file jni_util.c), we have to call jni_FindClass() to convert the symbolic class name "java.nio.charset.Charset" into a class reference. But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a special handling if called from java.lang.ClassLoader$NativeLibrary to ensure that JNI_OnLoad/JNI_OnUnload are executed in the correct class context: instanceKlassHandle k (THREAD, thread->security_get_caller_class(0)); if (k.not_null()) { loader = Handle(THREAD, k->class_loader()); // Special handling to make sure JNI_OnLoad and JNI_OnUnload are executed // in the correct class context. if (loader.is_null() && k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { JavaValue result(T_OBJECT); JavaCalls::call_static(&result, k, vmSymbols::getFromClass_name(), vmSymbols::void_class_signature(), thread); if (HAS_PENDING_EXCEPTION) { Handle ex(thread, thread->pending_exception()); CLEAR_PENDING_EXCEPTION; THROW_HANDLE_0(ex); } So if that's the case and jni_FindClass() was reallycalled from ClassLoader$NativeLibrary, then jni_FindClass() calles ClassLoader$NativeLibrary().getFromClass() to find out the corresponding context class which is supposed to be saved there in a field of type java.util.Stack named "nativeLibraryContext": // Invoked in the VM to determine the context class in // JNI_Load/JNI_Unload static Class<?> getFromClass() { return ClassLoader.nativeLibraryContext.peek().fromClass; } Unfortunately, "nativeLibraryContext" doesn't contain any entry at this point and the invocation of Stack.peek() will throw the exception shown before. In general, the "nativeLibraryContext" stack will be filled later on in Runtime.loadLibrary0() like this: NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); nativeLibraryContext.push(lib); try { lib.load(name, isBuiltin); } finally { nativeLibraryContext.pop(); } such that it always contains at least one element later when jni_FindClass() will be invoked. So in summary, the problem is that the implementors of 8005716 didn't took into account that calling ClassLoader$NativeLibrary.findBuiltinLib() may trigger a call to jni_FindClass() if we are running on a system with an unsupported character encoding. I'd suggest the following fix for this problem: Change ClassLoader$NativeLibrary().getFromClass() to return null if the stack is empty instead of throwing an exception: static Class<?> getFromClass() { return ClassLoader.nativeLibraryContext.empty() ? null : ClassLoader.nativeLibraryContext.peek().fromClass; } Unfortunately this also requires a HotSpot change in jni_FindClass() in order to properly handle the new 'null' return value: if (k.not_null()) { loader = Handle(THREAD, k->class_loader()); // Special handling to make sure JNI_OnLoad and JNI_OnUnload are executed // in the correct class context. if (loader.is_null() && k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { JavaValue result(T_OBJECT); JavaCalls::call_static(&result, k, vmSymbols::getFromClass_name(), vmSymbols::void_class_signature(), thread); if (HAS_PENDING_EXCEPTION) { Handle ex(thread, thread->pending_exception()); CLEAR_PENDING_EXCEPTION; THROW_HANDLE_0(ex); } oop mirror = (oop) result.get_jobject(); if (oopDesc::is_null(mirror)) { loader = Handle(THREAD, SystemDictionary::java_system_loader()); } else { loader = Handle(THREAD, InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); protection_domain = Handle(THREAD, InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); } } } else { // We call ClassLoader.getSystemClassLoader to obtain the system class loader. loader = Handle(THREAD, SystemDictionary::java_system_loader()); } These changes are sufficient to solve the problem in Java 8. Unfortunately, that's still not enough in Java 9 because there the loading of the extended charsets has been delegated to ServiceLoader. But ServiceLoader calls ClassLoader.getBootstrapResources() which calls sun.misc.Launcher.getBootstrapClassPath(). This leads to another problem during class initialization of sun.misc.Launcher if running on an unsupported locale. The first thing done in sun.misc.Launcher.<clinit> is the initialisation of the bootstrap URLClassPath in the Launcher. However this initialisation will eventually call Charset.isSupported() and if we are running on an unsupported locale this will inevitably end in another recursive call to ServiceLoader. But as explained below, ServiceLoader will query the Launcher's bootstrap URLClassPath which will be still uninitialized at that point. So we'll have to additionally guard guard against this situation on JDK 9 like this: private static Charset lookupExtendedCharset(String charsetName) { if (!sun.misc.VM.isBooted() || // see lookupViaProviders() sun.misc.Launcher.getBootstrapClassPath() == null) return null; This fixes the crashes, but still at the price of not having the extended charsets available during initialization until Launcher.getBootstrapClassPath is set up properly. This may be still a problem if the jdk is installed in a directory which contains characters specific to an extended encoding or if we have such characters in the command line arguments. Thank you and best regards, Volker *Mixed stack trace of the initial EmptyStackException for unsupported charsets described before:* Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j java.util.Stack.peek()Ljava/lang/Object;+1 j java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 v ~StubRoutines::call_stub V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b4 V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x45 V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x8b V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d V [libjvm.so+0x9e6588] jni_FindClass+0x428 C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff C [libjava.so+0x21cae] jnuEncodingSupported+0x61 C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 C [libjava.so+0xedcd] Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b j java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 j java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 j java.lang.System.initializeSystemClass()V+113 v ~StubRoutines::call_stub V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b4 V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x45 V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x8b V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 V [libjvm.so+0xe44444] Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x21a V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4a6 V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 C [libjli.so+0xa520] InitializeJVM+0x154 C [libjli.so+0x8024] JavaMain+0xcc

4 13

RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)
by Magnus Ihse Bursie 11 Jun '15

11 Jun '15

This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 [1] http://openjdk.java.net/jeps/223

10 21

RFR 9: 8086117: java/lang/Runtime/exec/LotsOfOutput.java still fails intermittently with Process consumes memory
by Roger Riggs 11 Jun '15

11 Jun '15

Please review a test change in the algorithm for detecting memory growth to resolve an intermittent reporting problem. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-lots-8086117/ Issue: https://bugs.openjdk.java.net/browse/JDK-8086117 Thanks, Roger

5 6

RFR 9: 8064956 : Remove sun.misc.ExtensionInstallationProvider and relevant classes
by Brent Christian 11 Jun '15

11 Jun '15

Hi, Please review my change for: Bug: https://bugs.openjdk.java.net/browse/JDK-8064956 Webrev: http://cr.openjdk.java.net/~bchristi/8064956/ After clearing some internal dependencies following the removal of the extension mechanism from JDK 9[1], we can now remove 4 extension-related classes from sun.misc: ExtensionDependency.java ExtensionInfo.java ExtensionInstallationException.java ExtensionInstallationProvider.java I will submit a CCC following code review. Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8061971

3 2

[9] RFR of 8081843: (fs) FileStore.getTotalSpace returns unexpected results with >2TB file systems
by Brian Burkhalter 10 Jun '15

10 Jun '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8081843 Patch: http://cr.openjdk.java.net/~bpb/8081843/webrev.00/ Summary: On Mac OS X use BSD system call statfs() instead of Standard C Library call statvfs() to obtain file system size statistics. Standard regression test run succeeded. Thanks, Brian

1 1

RFR 8076039: Remove the unused internal API sun.reflect.misc.FieldUtil.getDeclaredFields
by Srikanth 10 Jun '15

10 Jun '15

Greetings, Please review this patch to remove the said unused internal API - this has been reviewed by a couple of engineers already and is now submitted now for wider review. I have built JDK on all platforms and ran the tests to make sure this is safe. JBS: https://bugs.openjdk.java.net/browse/JDK-8076039 Webrev: http://cr.openjdk.java.net/~sadayapalam/8076039/webrev/ Thanks! Srikanth

3 4