From mikael.vidstedt at oracle.com Tue Apr 11 00:01:35 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:01:35 +0000 Subject: hg: portola/portola: 18 new changesets Message-ID: <201704110001.v3B01aGT004263@aojmv0008.oracle.com> Changeset: 794ff3bdb057 Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/794ff3bdb057 Added tag jdk-9+162 for changeset 21b063d75b3e ! .hgtags Changeset: a9fce4976c14 Author: lana Date: 2017-03-25 01:43 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/a9fce4976c14 Merge ! .hgtags Changeset: fe226259b01d Author: asemenyuk Date: 2017-03-30 21:23 +0200 URL: http://hg.openjdk.java.net/portola/portola/rev/fe226259b01d 8177770: Need more precise control on build system logging Reviewed-by: ihse, erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in + common/bin/shell-profiler.sh - common/bin/shell-tracer.sh ! make/Init.gmk ! make/InitSupport.gmk ! make/common/MakeBase.gmk Changeset: 1accf96fa79b Author: prr Date: 2017-03-06 10:40 -0800 URL: http://hg.openjdk.java.net/portola/portola/rev/1accf96fa79b Merge ! common/autoconf/generated-configure.sh Changeset: 6fea867479ea Author: prr Date: 2017-03-10 10:33 -0800 URL: http://hg.openjdk.java.net/portola/portola/rev/6fea867479ea Merge Changeset: 08d2d5b9ad20 Author: prr Date: 2017-03-16 09:50 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/08d2d5b9ad20 Merge - README-builds.html - README-builds.md - common/bin/update-build-readme.sh Changeset: d4d6daaef6f1 Author: prr Date: 2017-03-21 08:48 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/d4d6daaef6f1 Merge Changeset: 16d1c3ff3d0e Author: alanb Date: 2017-03-22 16:25 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/16d1c3ff3d0e 8174823: Module system implementation refresh (3/2017) Reviewed-by: erikj, mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com, sundararajan.athijegannathan at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! make/CreateJmods.gmk ! make/Images.gmk Changeset: 277c9c31206f Author: alanb Date: 2017-03-22 18:41 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/277c9c31206f Merge ! common/autoconf/generated-configure.sh Changeset: c38c6b270ccc Author: lana Date: 2017-03-23 22:56 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/c38c6b270ccc Merge Changeset: 41d9f0545d53 Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/41d9f0545d53 Added tag jdk-9+163 for changeset c38c6b270ccc ! .hgtags Changeset: 66df71217ba3 Author: mchung Date: 2017-03-29 09:41 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/66df71217ba3 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! make/Javadoc.gmk ! make/Main.gmk Changeset: 04d60d5ae6fd Author: ihse Date: 2017-03-30 08:53 +0200 URL: http://hg.openjdk.java.net/portola/portola/rev/04d60d5ae6fd 8177634: Fix for 8175307 may cause linker errors on OS X 10.9 Reviewed-by: dholmes, erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 148642751a9f Author: erikj Date: 2017-03-30 10:37 +0200 URL: http://hg.openjdk.java.net/portola/portola/rev/148642751a9f 8177135: OpenJDK 9 freetype needs msvcr100.dll Reviewed-by: ihse, prr ! common/conf/jib-profiles.js Changeset: 7810f75d016a Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/7810f75d016a Merge Changeset: ccfda1c4e17d Author: lana Date: 2017-04-06 04:48 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/ccfda1c4e17d Merge ! .hgtags ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in - common/bin/shell-tracer.sh ! common/conf/jib-profiles.js Changeset: 6fe9f8461672 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/6fe9f8461672 Added tag jdk-9+164 for changeset 7810f75d016a ! .hgtags Changeset: 8ec175c61fc3 Author: lana Date: 2017-04-08 03:24 +0000 URL: http://hg.openjdk.java.net/portola/portola/rev/8ec175c61fc3 Merge ! .hgtags - common/bin/shell-tracer.sh From mikael.vidstedt at oracle.com Tue Apr 11 00:01:39 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:01:39 +0000 Subject: hg: portola/portola/corba: 10 new changesets Message-ID: <201704110001.v3B01djg004362@aojmv0008.oracle.com> Changeset: 31dddeed0943 Author: mchung Date: 2017-03-15 18:07 -0700 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/31dddeed0943 8176815: Remove StackFramePermission and use RuntimePermission for stack walking Reviewed-by: alanb, bchristi ! src/java.corba/share/classes/sun/corba/Bridge.java Changeset: 18ffcf99a3b4 Author: lana Date: 2017-03-16 17:55 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/18ffcf99a3b4 Merge Changeset: 493011dee80e Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/493011dee80e Added tag jdk-9+162 for changeset 18ffcf99a3b4 ! .hgtags Changeset: 04c3dc7f1cbf Author: lana Date: 2017-03-25 01:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/04c3dc7f1cbf Merge ! .hgtags Changeset: 48a6b541153d Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/48a6b541153d Added tag jdk-9+163 for changeset 493011dee80e ! .hgtags Changeset: 8e9b64d90b69 Author: mchung Date: 2017-03-29 09:42 -0700 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/8e9b64d90b69 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! src/java.corba/share/classes/module-info.java Changeset: 965bbae30727 Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/965bbae30727 Merge Changeset: 8aa7044a5b59 Author: lana Date: 2017-04-06 04:50 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/8aa7044a5b59 Merge ! .hgtags Changeset: a510b2201154 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/a510b2201154 Added tag jdk-9+164 for changeset 965bbae30727 ! .hgtags Changeset: 5d6d891bb36d Author: lana Date: 2017-04-08 03:25 +0000 URL: http://hg.openjdk.java.net/portola/portola/corba/rev/5d6d891bb36d Merge ! .hgtags From mikael.vidstedt at oracle.com Tue Apr 11 00:01:45 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:01:45 +0000 Subject: hg: portola/portola/hotspot: 42 new changesets Message-ID: <201704110001.v3B01k8W004515@aojmv0008.oracle.com> Changeset: 2980b6adfe69 Author: iignatyev Date: 2017-03-05 22:25 -0800 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/2980b6adfe69 8172457: JarDirTest.java fails after recent change Reviewed-by: iveresov ! test/ProblemList.txt ! test/testlibrary_tests/ctw/CtwTest.java Changeset: 932b4ec7397f Author: hseigel Date: 2017-03-06 09:45 -0500 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/932b4ec7397f 8175383: JVM should throw NCDFE if ACC_MODULE and CONSTANT_Module/Package are set Summary: If bad constant is seen, save it to throw CFE if ACC_MODULE is not in access_flags Reviewed-by: dholmes, acorn, lfoltan, gtriantafill ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp + test/runtime/constantPool/ACCModule52.java + test/runtime/constantPool/ConstModule.java Changeset: e4f863a6da36 Author: jwilhelm Date: 2017-03-06 21:28 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/e4f863a6da36 Merge Changeset: 38f38c10a11d Author: neliasso Date: 2017-03-06 14:08 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/38f38c10a11d 8164954: split_if creates empty phi and region nodes Summary: Don't split if all edges will be moved to new phi Reviewed-by: kvn, vlivanov ! src/share/vm/opto/ifnode.cpp Changeset: 6fb85042b428 Author: kvn Date: 2017-03-07 09:32 -0800 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/6fb85042b428 8176238: [AOT] failure to build jdk.vm.compier with --with-jobs=1 configure flag Summary: add --add-modules jdk.internal.vm.ci to Graal annotation process command line. Reviewed-by: iveresov, mchung ! make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk Changeset: fc60138effe1 Author: hseigel Date: 2017-03-08 09:04 -0500 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/fc60138effe1 8176147: JVM should throw CFE for duplicate Signature attributes Summary: Add the needed checks to ClasFileParser for duplicate Signature attributes. Reviewed-by: dholmes, gtriantafill ! src/share/vm/classfile/classFileParser.cpp + test/runtime/duplAttributes/DupSignatureAttrs.jcod + test/runtime/duplAttributes/TestDupSignatureAttr.java Changeset: ee79788e8427 Author: jwilhelm Date: 2017-03-11 23:23 -0800 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/ee79788e8427 Merge Changeset: b01c519b715e Author: jwilhelm Date: 2017-03-16 12:09 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/b01c519b715e Merge - README Changeset: 11713ac0d70d Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/11713ac0d70d Added tag jdk-9+162 for changeset b01c519b715e ! .hgtags Changeset: bf06b849b50d Author: lana Date: 2017-03-25 01:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/bf06b849b50d Merge ! .hgtags - test/gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java - test/gc/startup_warnings/TestDefNewCMS.java - test/gc/startup_warnings/TestParNewCMS.java - test/gc/startup_warnings/TestParNewSerialOld.java - test/gc/startup_warnings/TestUseAutoGCSelectPolicy.java - test/runtime/NMT/AutoshutdownNMT.java Changeset: 55e3f1f3d0a7 Author: rraghavan Date: 2017-03-09 00:16 -0800 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/55e3f1f3d0a7 8175345: Reported null pointer dereference defect groups Summary: Added required explicit NULL checks Reviewed-by: thartmann, kvn ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 83906886441f Author: zmajo Date: 2017-03-09 14:27 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/83906886441f 8175340: Possible invalid memory accesses due to ciMethodData::bci_to_data() returning NULL Summary: Check values returned by ciMethodData::bci_to_data() where necessary. Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/opto/parse2.cpp Changeset: 6868eb69ce70 Author: mgerdin Date: 2017-03-09 16:58 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/6868eb69ce70 8176363: Incorrect lock rank for G1 PtrQueue related locks Reviewed-by: mgronlun, coleenp, kbarrett, dholmes, tschatzl ! src/share/vm/runtime/mutexLocker.cpp Changeset: 75549135a21f Author: hseigel Date: 2017-03-13 16:23 -0400 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/75549135a21f 8176471: [TESTBUG] runtime/modules/IgnoreModulePropertiesTest.java fails with OpenJDK: java.lang.RuntimeException: 'java version ' missing from stdout/stderr Summary: Check for strings such as " version " and "Runtime Environment" that appear in 'java -version' for both open and closed builds. Reviewed-by: coleenp ! test/runtime/modules/IgnoreModulePropertiesTest.java Changeset: eef6e15f993a Author: jwilhelm Date: 2017-03-13 15:56 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/eef6e15f993a Merge Changeset: a06c552214ed Author: stuefe Date: 2017-03-13 21:46 -0400 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/a06c552214ed 8176442: [aix] assert(_thr_current == 0L) failed: Thread::current already initialized Summary: Revert Thread::current() back to pthread library based TLS on AIX. Reviewed-by: dholmes ! src/share/vm/utilities/globalDefinitions_xlc.hpp Changeset: 86df8cfd7fd5 Author: jcm Date: 2017-03-13 23:36 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/86df8cfd7fd5 8176573: Do not use FLAG_SET_ERGO to update MaxRAM for emulated client Summary: used FLAG_SET_DEFAULT to update MaxRAM Reviewed-by: kvn ! src/share/vm/compiler/compilerDefinitions.cpp Changeset: 928c06e1f603 Author: rehn Date: 2017-03-14 12:00 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/928c06e1f603 8176098: Deprecate FlatProfiler Reviewed-by: shade, coleenp ! src/share/vm/Xusage.txt ! src/share/vm/runtime/arguments.cpp Changeset: 59ba61c8fa7e Author: simonis Date: 2017-03-13 16:07 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/59ba61c8fa7e 8176505: Wrong assertion 'should be an array copy/clone' in arraycopynode.cpp Reviewed-by: thartmann, roland ! src/share/vm/opto/arraycopynode.cpp + test/compiler/arraycopy/TestObjectArrayCopy.java Changeset: 03ca64e4447c Author: redestad Date: 2017-03-15 13:03 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/03ca64e4447c 8176593: Throwable::getStackTrace performance regression Reviewed-by: jiangli, iklam, coleenp, sspitsyn ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/stringTable.hpp Changeset: 03f4b62f3562 Author: roland Date: 2017-03-15 18:18 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/03f4b62f3562 8176513: Poor code quality for ByteBuffers Summary: Relaxes the condition under which MemBarCPUOrder nodes are added around unsafe accesses. Reviewed-by: vlivanov, kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: d2724225519c Author: jwilhelm Date: 2017-03-17 16:15 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/d2724225519c Merge Changeset: 027a986fe05d Author: alanb Date: 2017-03-22 16:26 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/027a986fe05d 8174823: Module system implementation refresh (3/2017) Reviewed-by: sspitsyn, dholmes, lfoltan, mchung ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp Changeset: a49c7926d151 Author: alanb Date: 2017-03-22 18:41 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/a49c7926d151 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 24599756cbef Author: lana Date: 2017-03-23 22:57 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/24599756cbef Merge Changeset: bb104b4b64dc Author: prr Date: 2017-03-24 08:56 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/bb104b4b64dc 8177346: hotspot change for 8176513 breaks jdk9 build on Ubuntu 16.04 Reviewed-by: dholmes, kvn, vlivanov ! src/share/vm/opto/library_call.cpp Changeset: 015084c7ef97 Author: mbaesken Date: 2017-03-25 00:00 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/015084c7ef97 8177531: libGetNamedModuleTest.c crash when printing NULL-pointer Summary: Fix the NULL-pointer issue Reviewed-by: stuefe, simonis, sspitsyn ! test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c Changeset: b0b56932255e Author: thartmann Date: 2017-03-27 10:12 +0200 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/b0b56932255e 8177095: Range check dependent CastII/ConvI2L is prematurely eliminated Summary: Disabled narrowing of range check dependent CastIIs (either through the CastII(AddI) optimization or through CastIINode::Ideal). Reviewed-by: vlivanov, kvn ! src/share/vm/opto/castnode.cpp ! src/share/vm/opto/convertnode.cpp ! test/compiler/loopopts/TestLoopPeeling.java Changeset: 983fe2075557 Author: adinn Date: 2017-03-27 06:18 -0400 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/983fe2075557 8177661: AArch64: Incorrect C2 patterns cause system register corruption Summary: Correct ad rule output register types from iRegX to iRegXNoSp Reviewed-by: aph, kvn ! src/cpu/aarch64/vm/aarch64.ad Changeset: 60721d6ff1ac Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/60721d6ff1ac Added tag jdk-9+163 for changeset 983fe2075557 ! .hgtags Changeset: fa10bec35262 Author: mdoerr Date: 2017-03-20 11:32 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/fa10bec35262 8176518: C2: Invalid ImplicitNullChecks with non-protected heap base Summary: Avoid generating implicit null checks if heap base is not protected Reviewed-by: zmajo ! src/share/vm/opto/lcm.cpp + test/compiler/c2/TestNPEHeapBased.java Changeset: 40ad6af5e434 Author: jwilhelm Date: 2017-03-20 23:49 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/40ad6af5e434 Merge Changeset: 8afdef5de101 Author: rehn Date: 2017-03-21 16:36 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/8afdef5de101 8177092: [TESTBUG] JMX test on MinimalVM fails after fix for 8176533 Reviewed-by: dholmes, mlarsson ! test/runtime/MinimalVM/JMX.java Changeset: b163435e40b3 Author: mgerdin Date: 2017-03-22 15:25 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/b163435e40b3 8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles Reviewed-by: kbarrett, coleenp, tschatzl ! make/test/JtregNative.gmk ! src/cpu/aarch64/vm/jniFastGetField_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp ! src/cpu/arm/vm/interp_masm_arm.cpp ! src/cpu/arm/vm/interp_masm_arm.hpp ! src/cpu/arm/vm/jniFastGetField_arm.cpp ! src/cpu/arm/vm/macroAssembler_arm.cpp ! src/cpu/arm/vm/macroAssembler_arm.hpp ! src/cpu/arm/vm/sharedRuntime_arm.cpp ! src/cpu/arm/vm/templateInterpreterGenerator_arm.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp ! src/cpu/s390/vm/macroAssembler_s390.cpp ! src/cpu/s390/vm/macroAssembler_s390.hpp ! src/cpu/s390/vm/sharedRuntime_s390.cpp ! src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp + test/runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java + test/runtime/jni/CallWithJNIWeak/libCallWithJNIWeak.c + test/runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java + test/runtime/jni/ReturnJNIWeak/libReturnJNIWeak.c Changeset: 838393a7baa6 Author: jwilhelm Date: 2017-03-23 15:06 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/838393a7baa6 Merge Changeset: dabd810a9825 Author: dholmes Date: 2017-03-23 17:15 -0400 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/dabd810a9825 8165358: vmassert_status is not debug-only Reviewed-by: dsamersoff, stuefe, zgu ! src/share/vm/utilities/debug.hpp Changeset: c68024d52834 Author: jwilhelm Date: 2017-03-25 00:31 +0100 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/c68024d52834 Merge Changeset: b70c17184fdb Author: jwilhelm Date: 2017-03-30 19:55 +0200 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/b70c17184fdb Merge Changeset: 0af429be8bba Author: neugens Date: 2017-03-29 15:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/0af429be8bba 8177390: java -version does not differentiate between which port of AArch64 is used Reviewed-by: aph, dholmes ! make/lib/CompileJvm.gmk ! test/test_env.sh Changeset: acaf29461f2c Author: lana Date: 2017-04-06 04:50 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/acaf29461f2c Merge ! .hgtags ! src/share/vm/runtime/arguments.cpp - test/gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java - test/gc/startup_warnings/TestDefNewCMS.java - test/gc/startup_warnings/TestParNewCMS.java - test/gc/startup_warnings/TestParNewSerialOld.java - test/gc/startup_warnings/TestUseAutoGCSelectPolicy.java - test/runtime/NMT/AutoshutdownNMT.java Changeset: e2a24f3510e9 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/e2a24f3510e9 Added tag jdk-9+164 for changeset 0af429be8bba ! .hgtags Changeset: 8295ca08f5cb Author: lana Date: 2017-04-08 03:24 +0000 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/8295ca08f5cb Merge ! .hgtags - test/gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java - test/gc/startup_warnings/TestDefNewCMS.java - test/gc/startup_warnings/TestParNewCMS.java - test/gc/startup_warnings/TestParNewSerialOld.java - test/gc/startup_warnings/TestUseAutoGCSelectPolicy.java - test/runtime/NMT/AutoshutdownNMT.java From mikael.vidstedt at oracle.com Tue Apr 11 00:01:54 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:01:54 +0000 Subject: hg: portola/portola/jaxp: 16 new changesets Message-ID: <201704110001.v3B01scb004693@aojmv0008.oracle.com> Changeset: 3b9128ad3e35 Author: mchung Date: 2017-03-14 15:52 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/3b9128ad3e35 8174977: Update license files with consistent license/notice names Reviewed-by: alanb, mchung Contributed-by: jeannette.hung at oracle.com ! src/java.xml/share/legal/bcel.md ! src/java.xml/share/legal/dom.md ! src/java.xml/share/legal/xalan.md ! src/java.xml/share/legal/xerces.md ! src/java.xml/share/legal/xmlresolver.md Changeset: fd5e28ea6ffb Author: joehw Date: 2017-03-14 18:56 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/fd5e28ea6ffb 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier Reviewed-by: darcy, rriggs, smarks ! src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java ! src/java.xml/share/classes/javax/xml/stream/XMLInputFactory.java ! src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java ! src/java.xml/share/classes/org/xml/sax/AttributeList.java ! src/java.xml/share/classes/org/xml/sax/DocumentHandler.java ! src/java.xml/share/classes/org/xml/sax/Parser.java ! src/java.xml/share/classes/org/xml/sax/helpers/ParserFactory.java Changeset: d02b6fbcab06 Author: lana Date: 2017-03-16 17:55 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/d02b6fbcab06 Merge Changeset: 4771597cc596 Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/4771597cc596 Added tag jdk-9+162 for changeset d02b6fbcab06 ! .hgtags Changeset: 4e0a47b2310d Author: lana Date: 2017-03-25 01:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/4e0a47b2310d Merge ! .hgtags Changeset: b66d95128345 Author: alanb Date: 2017-03-22 16:26 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/b66d95128345 8174823: Module system implementation refresh (3/2017) Reviewed-by: mchung ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java Changeset: c5553d4ca3b7 Author: alanb Date: 2017-03-22 18:41 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/c5553d4ca3b7 Merge Changeset: 4282c86136f0 Author: joehw Date: 2017-03-23 13:03 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/4282c86136f0 8177350: Two missed in the change from ${java.home}/lib to ${java.home}/conf Reviewed-by: lancea, mchung ! src/java.xml/share/classes/javax/xml/stream/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryFinder.java Changeset: 389969e18ba2 Author: lana Date: 2017-03-23 22:57 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/389969e18ba2 Merge Changeset: 92a38c75cd27 Author: joehw Date: 2017-03-23 21:28 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/92a38c75cd27 8176405: Catalog circular reference check did not work in certain scenarios Reviewed-by: rriggs, lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.properties ! src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java ! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java - test/javax/xml/jaxp/unittest/catalog/catalogReferCircle-itself.xml - test/javax/xml/jaxp/unittest/catalog/catalogReferCircle-left.xml - test/javax/xml/jaxp/unittest/catalog/catalogReferCircle-right.xml Changeset: fe0c5dfe9ce9 Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/fe0c5dfe9ce9 Added tag jdk-9+163 for changeset 92a38c75cd27 ! .hgtags Changeset: 086b6a500c6c Author: mchung Date: 2017-03-29 09:42 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/086b6a500c6c 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java Changeset: 6dc790a4e831 Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/6dc790a4e831 Merge Changeset: 451215719ec3 Author: lana Date: 2017-04-06 04:50 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/451215719ec3 Merge ! .hgtags Changeset: 8ecce2375af1 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/8ecce2375af1 Added tag jdk-9+164 for changeset 6dc790a4e831 ! .hgtags Changeset: 1f64e853c72b Author: lana Date: 2017-04-08 03:25 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxp/rev/1f64e853c72b Merge ! .hgtags From mikael.vidstedt at oracle.com Tue Apr 11 00:01:57 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:01:57 +0000 Subject: hg: portola/portola/jaxws: 11 new changesets Message-ID: <201704110001.v3B01vUL004773@aojmv0008.oracle.com> Changeset: f7fced955087 Author: mchung Date: 2017-03-14 15:52 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/f7fced955087 8174977: Update license files with consistent license/notice names Reviewed-by: alanb, mchung Contributed-by: jeannette.hung at oracle.com ! src/jdk.xml.bind/share/legal/xmlresolver.md Changeset: 05d7b08e85c4 Author: lana Date: 2017-03-16 17:55 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/05d7b08e85c4 Merge Changeset: b8aebe5292f2 Author: lancea Date: 2017-03-16 16:50 -0400 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/b8aebe5292f2 8174728: Mark Java EE modules deprecated and for removal Reviewed-by: alanb ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 3890f96e8995 Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/3890f96e8995 Added tag jdk-9+162 for changeset b8aebe5292f2 ! .hgtags Changeset: 70d4fbe7e6da Author: lana Date: 2017-03-25 01:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/70d4fbe7e6da Merge ! .hgtags Changeset: 22b17dea56eb Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/22b17dea56eb Added tag jdk-9+163 for changeset 3890f96e8995 ! .hgtags Changeset: ee1849f16695 Author: mchung Date: 2017-03-29 09:42 -0700 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/ee1849f16695 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 1a52de2da827 Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/1a52de2da827 Merge Changeset: 3c21e3777f7d Author: lana Date: 2017-04-06 04:50 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/3c21e3777f7d Merge ! .hgtags Changeset: b92bbd3a5613 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/b92bbd3a5613 Added tag jdk-9+164 for changeset 1a52de2da827 ! .hgtags Changeset: ac7e572a6a6b Author: lana Date: 2017-04-08 03:25 +0000 URL: http://hg.openjdk.java.net/portola/portola/jaxws/rev/ac7e572a6a6b Merge ! .hgtags From mikael.vidstedt at oracle.com Tue Apr 11 00:02:18 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:02:18 +0000 Subject: hg: portola/portola/nashorn: 6 new changesets Message-ID: <201704110002.v3B02IKx005039@aojmv0008.oracle.com> Changeset: 5e5e436543da Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/nashorn/rev/5e5e436543da Added tag jdk-9+162 for changeset 2cd29b339692 ! .hgtags Changeset: a80f117fe9e4 Author: lana Date: 2017-03-25 01:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/nashorn/rev/a80f117fe9e4 Merge ! .hgtags Changeset: b473fab09baa Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/nashorn/rev/b473fab09baa Added tag jdk-9+163 for changeset 5e5e436543da ! .hgtags Changeset: 20014f4cea19 Author: lana Date: 2017-04-06 04:50 +0000 URL: http://hg.openjdk.java.net/portola/portola/nashorn/rev/20014f4cea19 Merge ! .hgtags Changeset: 8c8c38891345 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/nashorn/rev/8c8c38891345 Added tag jdk-9+164 for changeset b473fab09baa ! .hgtags Changeset: e6bc0ad505e6 Author: lana Date: 2017-04-08 03:24 +0000 URL: http://hg.openjdk.java.net/portola/portola/nashorn/rev/e6bc0ad505e6 Merge ! .hgtags From mikael.vidstedt at oracle.com Tue Apr 11 00:02:15 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:02:15 +0000 Subject: hg: portola/portola/langtools: 42 new changesets Message-ID: <201704110002.v3B02Frb004944@aojmv0008.oracle.com> Changeset: 95d65add96a9 Author: ksrini Date: 2017-03-13 16:46 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/95d65add96a9 8175219: javadoc should exit when it encounters compilation errors. Reviewed-by: jjg, bpatel ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocEnter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! test/jdk/javadoc/doclet/testClassTree/pkg/Coin.java ! test/jdk/javadoc/doclet/testMissingType/TestMissingType.java ! test/jdk/javadoc/doclet/testModules/moduleB/testpkgmdlB/AnnotationType.java ! test/jdk/javadoc/doclet/testModules/moduleB/testpkgmdlB/AnnotationTypeUndocumented.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/pkg/C.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/pkg/D.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testTypeAnnotations/typeannos/Receivers.java + test/jdk/javadoc/tool/IgnoreSourceErrors.java ! test/jdk/javadoc/tool/ReleaseOption.java ! test/jdk/javadoc/tool/T6551367.java ! test/jdk/javadoc/tool/badSuper/BadSuper.java ! test/jdk/javadoc/tool/outputRedirect/p/OutputRedirect.java Changeset: 0aaffc5096c0 Author: ksrini Date: 2017-03-13 17:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/0aaffc5096c0 8176539: javadoc ignores module-info files on the command line Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties + test/jdk/javadoc/tool/modules/CommandLineFiles.java ! test/jdk/javadoc/tool/modules/ModuleTestBase.java ! test/jdk/javadoc/tool/modules/Modules.java ! test/jdk/javadoc/tool/modules/PackageOptions.java Changeset: 24fa5d195595 Author: jlahoda Date: 2017-03-14 07:11 +0100 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/24fa5d195595 8175057: module-info on patch path should not produce an error Summary: Allowing module-infos on patch paths during compilation. Reviewed-by: jjg, ksrini ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/ModuleInfoWithPatchedModuleClassoutput.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/additional/module-info.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/patchmodule/java.compiler/javax/lang/model/element/Extra.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/ModuleInfoWithPatchedModule.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/patchmodule/java.compiler/javax/lang/model/element/Extra.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/patchmodule/java.compiler/module-info.java ! test/tools/javac/modules/CompileModulePatchTest.java ! test/tools/javac/modules/EdgeCases.java + test/tools/javac/modules/ModuleInfoPatchPath.java Changeset: d457e90d4906 Author: jlahoda Date: 2017-03-14 08:19 +0100 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/d457e90d4906 8176045: No compile error when a package is not declared Summary: Fixing handling of otherwise empty files with package clauses and empty files without package clauses. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/tools/javac/modules/EdgeCases.java Changeset: adef848660f9 Author: jlahoda Date: 2017-03-14 10:51 +0100 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/adef848660f9 8175119: Need to specify module of types created by Filer.createSourceFile/Filer.createClassFile? Summary: Clarifications and improvements to jx.a.processing.Filer for creating and reading files in and from modules. Reviewed-by: darcy, jjg ! src/java.compiler/share/classes/javax/annotation/processing/Filer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/modules/AnnotationProcessing.java Changeset: 0025bb118860 Author: mcimadamore Date: 2017-03-15 11:42 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/0025bb118860 8176534: Missing check against target-type during applicability inference Summary: PartiallyInferredMethodType should check against target if unchecked conversion occurred Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8176534/T8176534.java + test/tools/javac/generics/inference/8176534/T8176534.out + test/tools/javac/generics/inference/8176534/TestUncheckedCalls.java Changeset: 147a9390f8e2 Author: ksrini Date: 2017-03-15 06:30 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/147a9390f8e2 8176778: javadoc does not produce summary pages for aggregated modules Reviewed-by: bpatel, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! test/jdk/javadoc/doclet/testModules/TestModules.java + test/jdk/javadoc/doclet/testModules/moduleT/module-info.java Changeset: 43a83431f19d Author: jlahoda Date: 2017-03-15 15:46 +0100 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/43a83431f19d 8176743: tools/javac/modules/MOptionTest.java test fails on Mac Summary: Correctly preferring classfiles over source files when timestamps match. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! test/tools/javac/modules/MOptionTest.java Changeset: 11ccc79e4126 Author: smarks Date: 2017-03-15 13:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/11ccc79e4126 8171395: (jdeprscan) add comments to L10N message file Reviewed-by: ljiang, darcy ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties Changeset: efbe078a0f67 Author: bpatel Date: 2017-03-15 14:18 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/efbe078a0f67 8176794: javadoc search results sorted incorrectly on packages Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js ! test/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: f9ff519b0e6e Author: bpatel Date: 2017-03-15 16:12 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/f9ff519b0e6e 8175200: Long method signatures disturb Method Summary table Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java ! test/jdk/javadoc/doclet/testClassLinks/TestClassLinks.java ! test/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/jdk/javadoc/doclet/testIndentation/TestIndentation.java ! test/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/jdk/javadoc/doclet/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/jdk/javadoc/doclet/testMemberInheritence/TestMemberInheritence.java ! test/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestBadOverride.java ! test/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testUseOption/TestUseOption.java Changeset: 7a7efd549ab6 Author: lana Date: 2017-03-16 17:56 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/7a7efd549ab6 Merge - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/ModuleInfoWithPatchedModuleClassoutput.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/additional/module-info.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/patchmodule/java.compiler/javax/lang/model/element/Extra.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/ModuleInfoWithPatchedModule.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/patchmodule/java.compiler/javax/lang/model/element/Extra.java - test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/patchmodule/java.compiler/module-info.java Changeset: de37b2959c68 Author: jjg Date: 2017-03-16 14:40 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/de37b2959c68 8176900: TreePosTest should disable annotation processing Reviewed-by: vromero ! test/tools/javac/tree/TreePosTest.java Changeset: 7b92442057a8 Author: jjg Date: 2017-03-16 17:13 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/7b92442057a8 8177014: tools/javac/tree/TreePosTest.java test fails with IllegalArgumentException Reviewed-by: redestad ! test/tools/javac/tree/TreePosTest.java Changeset: 440c45c2e8ce Author: ksrini Date: 2017-03-16 18:50 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/440c45c2e8ce 8175346: javadoc does not handle Locations correctly with --patch-module Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/jdk/javadoc/tool/modules/ModuleTestBase.java ! test/jdk/javadoc/tool/modules/Modules.java + test/jdk/javadoc/tool/modules/PatchModules.java + test/jdk/javadoc/tool/modules/ReleaseOptions.java Changeset: 8cfb71a78258 Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/8cfb71a78258 Added tag jdk-9+162 for changeset 440c45c2e8ce ! .hgtags Changeset: c07524646483 Author: lana Date: 2017-03-25 01:44 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/c07524646483 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties Changeset: ad45b4519f1b Author: jjg Date: 2017-03-20 15:32 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/ad45b4519f1b 8176231: javadoc -javafx creates bad link when Property is an array of objects Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/javadoc/doclet/testProperty/TestProperty.java + test/jdk/javadoc/doclet/testProperty/pkg/MyClass.java + test/jdk/javadoc/doclet/testProperty/pkg/MyClassT.java + test/jdk/javadoc/doclet/testProperty/pkg/MyObj.java + test/jdk/javadoc/doclet/testProperty/pkg/ObjectProperty.java + test/jdk/javadoc/doclet/testProperty/pkg/SimpleObjectProperty.java Changeset: 88cdf1b96e73 Author: alanb Date: 2017-03-22 16:27 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/88cdf1b96e73 8174823: Module system implementation refresh (3/2017) Reviewed-by: jjg, mchung ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleTarget_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/ProblemList.txt Changeset: aa10ddad1b6e Author: alanb Date: 2017-03-22 18:41 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/aa10ddad1b6e Merge Changeset: 5d030fd9de7a Author: jjg Date: 2017-03-23 10:58 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/5d030fd9de7a 8176836: Provide Taglet with context Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/UserTaglet.java ! test/jdk/javadoc/doclet/testLegacyTaglet/Check.java ! test/jdk/javadoc/doclet/testLegacyTaglet/ToDoTaglet.java ! test/jdk/javadoc/doclet/testLegacyTaglet/UnderlineTaglet.java + test/jdk/javadoc/doclet/testUserTaglet/InfoTaglet.java + test/jdk/javadoc/doclet/testUserTaglet/TestUserTaglet.java + test/jdk/javadoc/doclet/testUserTaglet/pkg/C.java ! test/jdk/javadoc/tool/EnsureNewOldDoclet.java ! test/jdk/javadoc/tool/api/basic/taglets/UnderlineTaglet.java Changeset: ee787e34231d Author: ksrini Date: 2017-03-23 14:18 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/ee787e34231d 8176481: javadoc does not consider mandated modules Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties + test/jdk/javadoc/tool/modules/MissingSourceModules.java ! test/jdk/javadoc/tool/modules/Modules.java ! test/jdk/javadoc/tool/modules/PatchModules.java Changeset: 54c1167ba68a Author: lana Date: 2017-03-23 22:57 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/54c1167ba68a Merge Changeset: b398971f7b6f Author: mcimadamore Date: 2017-03-24 12:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/b398971f7b6f 8177392: Fix default verbosity for IntelliJ Ant logger wrapper Summary: Adjust langtools ant build logger to be compatible with IJ 2017 Reviewed-by: jlahoda ! make/intellij/src/idea/LangtoolsIdeaAntLogger.java Changeset: 6d160fbd7d2e Author: mcimadamore Date: 2017-03-24 13:04 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/6d160fbd7d2e 8177097: Generic method reference returning wildcard parameterized type does not compile Summary: Captured cache should not be used during 'fake' attr checks Reviewed-by: vromero, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8177097/T8177097a.java + test/tools/javac/generics/inference/8177097/T8177097b.java Changeset: 24582dd2649a Author: vromero Date: 2017-03-24 06:40 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/24582dd2649a 8176714: javac is wrongly assuming that field JCMemberReference.overloadKind has been assigned to Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/T8176714/FieldOverloadKindNotAssignedTest.java + test/tools/javac/T8176714/TimingOfMReferenceCheckingTest01.java + test/tools/javac/T8176714/TimingOfMReferenceCheckingTest02.java Changeset: 4c09d6da5f6b Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/4c09d6da5f6b Added tag jdk-9+163 for changeset 24582dd2649a ! .hgtags Changeset: bef1cba2d0d9 Author: ksrini Date: 2017-03-27 17:53 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/bef1cba2d0d9 8175277: javadoc AssertionError when specified with release 8 Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/jdk/javadoc/tool/modules/ReleaseOptions.java Changeset: cc3c67b12ef1 Author: jlahoda Date: 2017-03-29 10:27 +0200 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/cc3c67b12ef1 8177311: Denied access when named module accesses unreferences package from the unnamed module Summary: Ensure access to the unnamed module is allowed if the given module reads the unnamed module. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/modules/EdgeCases.java Changeset: bb0649dbe925 Author: mchung Date: 2017-03-29 09:41 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/bb0649dbe925 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea Contributed-by: jonathan.gibbons at oracle.com, mandy.chung at oracle.com ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java Changeset: 3b47c6cb966e Author: lancea Date: 2017-03-29 16:31 -0400 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/3b47c6cb966e 8175013: Add Generated annotation Reviewed-by: darcy, alanb + src/java.compiler/share/classes/javax/annotation/processing/Generated.java Changeset: 573dfe4c63d4 Author: rfield Date: 2017-03-29 16:07 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/573dfe4c63d4 8177079: jshell tool: usability of /help for commands and sub-commands Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 132f24d279d1 Author: lana Date: 2017-03-30 17:24 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/132f24d279d1 Merge Changeset: 4c4738ddfbc0 Author: rfield Date: 2017-03-30 13:55 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/4c4738ddfbc0 8177078: jshell tool: fix documentation of /help shortcuts 8177735: jshell tool: /help /help -- typo "comand" 8177308: jshell tool: documentation: multiple start-up files and predefines not documented Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties Changeset: 0f4a3fa6bac0 Author: jjg Date: 2017-03-30 16:36 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/0f4a3fa6bac0 8177484: The old standard doclet should be deprecated for removal. Reviewed-by: ksrini ! make/CompileInterim.gmk ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: 5df3b79e6526 Author: redestad Date: 2017-03-31 08:59 +0200 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/5df3b79e6526 8175116: jtreg agentvms uses more virtual address space in langtool/test :tier1 runs Summary: Avoiding creation of an unnecessary read edge from jdk.compiler to a newly created unnamed module. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java Changeset: 33c818a75ec9 Author: jlahoda Date: 2017-03-31 10:46 +0200 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/33c818a75ec9 8177076: jshell tool: usability of completion Summary: Merging completion and documentation completion, assigning Shift-tab shortcut to fix actions. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/jdk/jshell/MergedTabShiftTabTest.java Changeset: 04d69a5db5e1 Author: ksrini Date: 2017-03-31 07:38 -0700 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/04d69a5db5e1 8177567: cache VisibleMemberMap Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java Changeset: c7f3df19667b Author: mcimadamore Date: 2017-04-03 12:40 +0100 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/c7f3df19667b 8177667: Langtools ant build has issues with Windows file separators Summary: Replace complex, non-portable regex logic for generating --patch-module option with a script mapper Reviewed-by: jjg, ksrini ! make/build.properties ! make/build.xml ! make/intellij/runConfigurations/javadoc.xml ! make/intellij/runConfigurations/jshell.xml Changeset: d2020e584c10 Author: lana Date: 2017-04-06 04:50 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/d2020e584c10 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 77a4b2e2e5be Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/77a4b2e2e5be Added tag jdk-9+164 for changeset c7f3df19667b ! .hgtags Changeset: ef9180164e08 Author: lana Date: 2017-04-08 03:25 +0000 URL: http://hg.openjdk.java.net/portola/portola/langtools/rev/ef9180164e08 Merge ! .hgtags From mikael.vidstedt at oracle.com Tue Apr 11 00:02:01 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 00:02:01 +0000 Subject: hg: portola/portola/jdk: 95 new changesets Message-ID: <201704110002.v3B025Y3004826@aojmv0008.oracle.com> Changeset: f7c7906df522 Author: weijun Date: 2017-03-22 17:24 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/f7c7906df522 8177085: Accept including .conf files in krb5.conf's includedir Reviewed-by: jnimeh ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! test/sun/security/krb5/config/Include.java Changeset: dec69a95e5c9 Author: bpb Date: 2017-03-13 13:38 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/dec69a95e5c9 8176221: Preferences docs contain reference to Sun's JRE Summary: Remove reference to "Sun's JRE" and add @implNote Reviewed-by: darcy ! src/java.prefs/share/classes/java/util/prefs/Preferences.java Changeset: f2f9d8ba1b28 Author: weijun Date: 2017-03-14 20:24 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/f2f9d8ba1b28 8176715: sun/security/krb5/auto/HttpNegotiateServer.java does not compile Reviewed-by: mullan ! test/sun/security/krb5/auto/HttpNegotiateServer.java Changeset: dbcdb8bcadd6 Author: mullan Date: 2017-03-14 08:35 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/dbcdb8bcadd6 8176503: Disable SHA-1 TLS Server Certificates Reviewed-by: vinnie, ascarpino ! src/java.base/share/conf/security/java.security Changeset: 341a471ff662 Author: mullan Date: 2017-03-14 08:35 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/341a471ff662 Merge Changeset: ded4aa6817b2 Author: dl Date: 2017-03-14 07:04 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/ded4aa6817b2 8176551: testCommonPoolThreadContextClassLoader fails with "Should throw SecurityException" Reviewed-by: martin, chegar, dholmes, amlu ! test/java/util/concurrent/tck/ForkJoinPool9Test.java Changeset: 9104479f9252 Author: mchung Date: 2017-03-14 15:52 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/9104479f9252 8174977: Update license files with consistent license/notice names Reviewed-by: alanb, mchung Contributed-by: jeannette.hung at oracle.com ! src/java.desktop/share/legal/colorimaging.md ! src/java.desktop/share/legal/jpeg.md ! src/java.desktop/share/legal/libpng.md ! src/java.desktop/share/legal/mesa3d.md ! src/java.desktop/unix/legal/fontconfig.md ! src/java.smartcardio/unix/legal/pcsclite.md ! src/java.xml.crypto/share/legal/santuario.md ! src/jdk.crypto.cryptoki/share/legal/pkcs11cryptotoken.md ! src/jdk.crypto.ec/share/legal/ecc.md Changeset: 2e09a4e9a954 Author: bpb Date: 2017-03-14 16:43 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/2e09a4e9a954 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java Summary: Replace two sleeps with CountDownLatch+sleep and Thread.join() Reviewed-by: rriggs, alanb ! test/java/nio/channels/Selector/SelectAndClose.java Changeset: 6bb7ec151fd4 Author: weijun Date: 2017-03-15 08:09 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/6bb7ec151fd4 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/krb5/auto/Basic.java Changeset: 8ac762a3d4a4 Author: mli Date: 2017-03-14 19:23 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/8ac762a3d4a4 8176566: @since value errors in types of java.base module Reviewed-by: martin, psandoz ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java ! src/java.base/share/classes/java/lang/invoke/LambdaConversionException.java ! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/MutableCallSite.java ! src/java.base/share/classes/java/lang/invoke/SerializedLambda.java ! src/java.base/share/classes/java/lang/invoke/SwitchPoint.java ! src/java.base/share/classes/java/lang/invoke/VolatileCallSite.java ! src/java.base/share/classes/java/nio/file/ClosedFileSystemException.java ! src/java.base/share/classes/java/nio/file/ClosedWatchServiceException.java ! src/java.base/share/classes/java/nio/file/FileSystemAlreadyExistsException.java ! src/java.base/share/classes/java/nio/file/FileSystemNotFoundException.java ! src/java.base/share/classes/java/nio/file/InvalidPathException.java ! src/java.base/share/classes/java/nio/file/ProviderMismatchException.java ! src/java.base/share/classes/java/nio/file/ProviderNotFoundException.java ! src/java.base/share/classes/java/nio/file/ReadOnlyFileSystemException.java ! src/java.base/share/classes/java/util/zip/ZipException.java Changeset: fccdf07c7c67 Author: mli Date: 2017-03-14 19:44 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/fccdf07c7c67 8176721: @since value errors java.sql module Reviewed-by: lancea ! src/java.sql/share/classes/java/sql/CallableStatement.java ! src/java.sql/share/classes/java/sql/Connection.java ! src/java.sql/share/classes/java/sql/DataTruncation.java ! src/java.sql/share/classes/java/sql/DatabaseMetaData.java ! src/java.sql/share/classes/java/sql/Date.java ! src/java.sql/share/classes/java/sql/Driver.java ! src/java.sql/share/classes/java/sql/DriverManager.java ! src/java.sql/share/classes/java/sql/DriverPropertyInfo.java ! src/java.sql/share/classes/java/sql/PreparedStatement.java ! src/java.sql/share/classes/java/sql/ResultSet.java ! src/java.sql/share/classes/java/sql/ResultSetMetaData.java ! src/java.sql/share/classes/java/sql/SQLException.java ! src/java.sql/share/classes/java/sql/SQLWarning.java ! src/java.sql/share/classes/java/sql/ShardingKeyBuilder.java ! src/java.sql/share/classes/java/sql/Statement.java ! src/java.sql/share/classes/java/sql/Time.java ! src/java.sql/share/classes/java/sql/Timestamp.java ! src/java.sql/share/classes/java/sql/Types.java ! src/java.sql/share/classes/javax/transaction/xa/XAException.java ! src/java.sql/share/classes/javax/transaction/xa/XAResource.java ! src/java.sql/share/classes/javax/transaction/xa/Xid.java Changeset: fc81607db2fb Author: redestad Date: 2017-03-15 19:33 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/fc81607db2fb 8176709: JarFileSystem::isMultiReleaseJar is incorrect Reviewed-by: mchung, sherman ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java ! test/jdk/nio/zipfs/MultiReleaseJarTest.java ! test/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java Changeset: b7ce1a971174 Author: wetmore Date: 2017-03-15 12:58 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b7ce1a971174 8176793: SecureRandom FIPS 140-2, Security Requirements for Cryptographic Modules link 404 Reviewed-by: mullan ! src/java.base/share/classes/java/security/SecureRandom.java Changeset: 48c2388ae277 Author: redestad Date: 2017-03-15 23:09 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/48c2388ae277 8176834: jdk/nio/zipfs/MultiReleaseJarTest.java test fails after JDK-8176709 Reviewed-by: mchung ! test/jdk/nio/zipfs/MultiReleaseJarTest.java Changeset: 50911d8e5cc5 Author: valeriep Date: 2017-03-15 22:57 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/50911d8e5cc5 8175251: Failed to load RSA private key from pkcs12 Summary: Enhanced DER library with extra arg to control leading-0 check Reviewed-by: mullan ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/java.base/share/classes/sun/security/util/DerInputBuffer.java ! src/java.base/share/classes/sun/security/util/DerInputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java ! test/sun/security/pkcs/pkcs8/PKCS8Test.java + test/sun/security/pkcs/pkcs8/TestLeadingZeros.java Changeset: 4d8290fb0f88 Author: smarks Date: 2017-03-15 17:17 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/4d8290fb0f88 8066640: clarify security checks in ObjectInputStream.enableResolveObject and ObjectOutputStream.enableReplaceObject Reviewed-by: chegar, darcy ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java Changeset: 1ee5af7d82a4 Author: mchung Date: 2017-03-15 18:08 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/1ee5af7d82a4 8176815: Remove StackFramePermission and use RuntimePermission for stack walking Reviewed-by: alanb, bchristi ! src/java.base/share/classes/java/lang/LiveStackFrame.java ! src/java.base/share/classes/java/lang/RuntimePermission.java - src/java.base/share/classes/java/lang/StackFramePermission.java ! src/java.base/share/classes/java/lang/StackWalker.java ! test/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java ! test/java/lang/StackWalker/GetCallerClassTest.java ! test/java/lang/StackWalker/stackwalk.policy ! test/java/lang/StackWalker/stackwalktest.policy Changeset: 5548e024cbcf Author: mli Date: 2017-03-15 19:24 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/5548e024cbcf 8176563: @since value errors in apis of java.base/java.logging module Reviewed-by: alanb, chegar, dfuchs, dholmes, martin, naoto, rriggs ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/ProcessBuilder.java ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.logging/share/classes/java/util/logging/LogManager.java Changeset: 832ae841344c Author: erikj Date: 2017-03-16 14:46 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/832ae841344c 8176849: jdk9 BCL builds fail after cleaning up temporary file ASSEMBLY_EXCEPTION Reviewed-by: ihse ! make/copy/Copy-java.base.gmk Changeset: 7b8e364b2faf Author: prappo Date: 2017-03-16 15:30 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/7b8e364b2faf 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem Reviewed-by: mr ! src/java.base/share/classes/java/lang/Runtime.java ! test/java/lang/Runtime/Version/Basic.java Changeset: e6ae37815239 Author: bpb Date: 2017-03-16 08:58 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e6ae37815239 8176846: (fc) Increase timeouts of and instrument some tests using FileChannel#write Summary: Change tests to improve odds of passing on slow file systems. Reviewed-by: clanger, rriggs ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/nio/channels/FileChannel/LoopingTruncate.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/channels/FileChannel/Transfers.java Changeset: a89d57a24005 Author: chegar Date: 2017-03-16 16:56 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/a89d57a24005 8176772: jar tool support to report automatic module names Reviewed-by: alanb, mchung ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! test/tools/jar/modularJar/Basic.java Changeset: 66967f5961da Author: lana Date: 2017-03-16 17:55 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/66967f5961da Merge - src/java.base/share/classes/java/lang/StackFramePermission.java Changeset: 3981152d47d4 Author: rriggs Date: 2017-03-16 15:40 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/3981152d47d4 8176272: (process) ProcessHandle::onExit fails to wait for non-child process Reviewed-by: chegar, stuefe ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java ! src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c ! test/java/lang/ProcessHandle/JavaChild.java ! test/java/lang/ProcessHandle/OnExitTest.java Changeset: 5eb2468e0861 Author: martin Date: 2017-03-16 13:10 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/5eb2468e0861 8176886: Remove stray @deprecated in Date#getDate Reviewed-by: naoto ! src/java.base/share/classes/java/util/Date.java Changeset: 45b226ad2e05 Author: lancea Date: 2017-03-16 16:56 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/45b226ad2e05 8174728: Mark Java EE modules deprecated and for removal Reviewed-by: alanb ! src/java.transaction/share/classes/module-info.java Changeset: a2b8bf9a32ce Author: prappo Date: 2017-03-16 22:58 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/a2b8bf9a32ce 8176882: Incorrect integer comparison in version numbers Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/Runtime.java ! test/java/lang/Runtime/Version/Basic.java Changeset: f8089e07c9f2 Author: bpb Date: 2017-03-17 08:38 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/f8089e07c9f2 8176895: (fc) Split java/nio/channels/FileChannel/Transfer.java into smaller tests Summary: Move sub-tests writing 4GB and 6GB files into two separate tests Reviewed-by: clanger ! test/java/nio/channels/FileChannel/Transfer.java + test/java/nio/channels/FileChannel/Transfer4GBFile.java + test/java/nio/channels/FileChannel/TransferTo6GBFile.java Changeset: f6bf027e88e9 Author: coffeys Date: 2017-03-20 09:18 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/f6bf027e88e9 8177144: sun/net/www/http/HttpClient/B8025710.java should run in ovm mode Reviewed-by: dfuchs, chegar ! test/sun/net/www/http/HttpClient/B8025710.java Changeset: af1ace480c5e Author: lana Date: 2017-03-23 22:31 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/af1ace480c5e Added tag jdk-9+162 for changeset f6bf027e88e9 ! .hgtags Changeset: 54fb507a5d0c Author: lana Date: 2017-03-25 01:43 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/54fb507a5d0c Merge ! .hgtags - src/java.base/macosx/native/launcher/jexec.c - src/java.base/unix/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! test/ProblemList.txt Changeset: 53142e39bfa7 Author: mullan Date: 2017-03-31 13:28 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/53142e39bfa7 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) Reviewed-by: weijun, vinnie ! src/java.base/share/classes/java/security/cert/X509CRL.java ! src/java.base/share/classes/java/security/cert/X509Certificate.java ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/java/security/cert/X509CRL/VerifyDefault.java + test/java/security/cert/X509Certificate/VerifyDefault.java ! test/java/security/testlibrary/CertUtils.java Changeset: c0aecf84349c Author: redestad Date: 2017-04-04 10:53 +0200 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/c0aecf84349c 8177631: Outdated performance advice in StringCoding Reviewed-by: sherman ! src/java.base/share/classes/java/lang/StringCoding.java Changeset: 61d6601e2948 Author: redestad Date: 2017-03-20 21:40 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/61d6601e2948 8177036: Class.checkMemberAccess throws NPE when calling Class methods via JNI Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/lang/Class.java Changeset: e4b869632f7d Author: amlu Date: 2017-03-21 20:20 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e4b869632f7d 8177313: Move FJExceptionTableLeak.java and ConfigChanges.java back to tier1 Reviewed-by: alanb ! test/TEST.groups Changeset: 8a14f9275ba9 Author: hseigel Date: 2017-03-13 16:23 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/8a14f9275ba9 8176471: [TESTBUG] runtime/modules/IgnoreModulePropertiesTest.java fails with OpenJDK: java.lang.RuntimeException: 'java version ' missing from stdout/stderr Summary: Check for strings such as " version " and "Runtime Environment" that appear in 'java -version' for both open and closed builds. Reviewed-by: coleenp ! test/sun/tools/jinfo/JInfoTest.java Changeset: e559d0c0985a Author: jwilhelm Date: 2017-03-13 15:56 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e559d0c0985a Merge Changeset: 9861a8803e52 Author: rehn Date: 2017-03-14 12:00 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/9861a8803e52 8176098: Deprecate FlatProfiler Reviewed-by: shade, coleenp ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 952d3df46b5b Author: jwilhelm Date: 2017-03-17 16:15 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/952d3df46b5b Merge Changeset: 0832f3508ecb Author: jwilhelm Date: 2017-03-21 16:39 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/0832f3508ecb Merge Changeset: 09774b62cec0 Author: alexsch Date: 2017-03-13 22:55 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/09774b62cec0 8175301: Java GUI hangs on Windows when Display set to 125% Reviewed-by: serb, azvegint ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java Changeset: 48ddfeefafac Author: psadhukhan Date: 2017-03-14 10:29 +0530 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/48ddfeefafac 8173123: [findbugs] javax.swing.text.* - Storing a reference to an externally mutable object into the internal representation Reviewed-by: serb, alexsch, prr ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java Changeset: 75a8a6117014 Author: dmarkov Date: 2017-03-14 09:03 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/75a8a6117014 8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter Reviewed-by: prr, serb ! src/java.desktop/share/classes/sun/awt/CustomCursor.java Changeset: 23f609916fba Author: serb Date: 2017-03-14 18:35 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/23f609916fba 8176177: The new SwingContainer annotation can be removed from javax.accessibility.AccessibleContext Reviewed-by: alexsch, malenkov ! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java + test/javax/swing/SwingContainer/SwingContainerIsForContainerOnly/SwingContainerIsForContainerOnly.java Changeset: b38931a57a60 Author: serb Date: 2017-03-15 18:56 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b38931a57a60 8176448: [macos] Popups in JCombobox and Choice have incorrect location in multiscreen systems Reviewed-by: alexsch, azvegint ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxPopup.java + test/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java ! test/javax/swing/plaf/basic/BasicComboPopup/7072653/bug7072653.java + test/javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java Changeset: 3556f4cd047b Author: alexsch Date: 2017-03-15 20:42 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/3556f4cd047b 8174845: Bad scaling on Windows with large fonts with Java 9ea Reviewed-by: serb, azvegint ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! test/javax/swing/plaf/metal/MetalIcons/MetalHiDPIIconsTest.java Changeset: 00c2a0d8e1cb Author: prr Date: 2017-03-15 11:14 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/00c2a0d8e1cb 8176530: JDK support for JavaFX modal print dialogs Reviewed-by: serb, psadhukhan, kcr + src/java.desktop/share/classes/sun/print/DialogOnTop.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintDialog.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp Changeset: e607ebd99004 Author: psadhukhan Date: 2017-03-15 12:55 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e607ebd99004 8176287: [macosx] The print test crashed with Nimbus L&F Reviewed-by: serb, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m Changeset: 88125261d41e Author: azvegint Date: 2017-03-16 01:40 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/88125261d41e 8176528: Progress state for window is not displayed in taskbar Reviewed-by: prr, serb ! src/java.desktop/share/classes/java/awt/Taskbar.java Changeset: b55ec235fc5f Author: vadim Date: 2017-03-16 16:45 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b55ec235fc5f 8176409: [findbugs] some files under com.apple.laf with variable isn't final but should be Reviewed-by: serb, azvegint ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonRadioUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonToggleUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileView.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaGroupBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaHighlighter.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMnemonicHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaProgressBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaSliderUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaToolTipUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java Changeset: 9158f22042bb Author: prr Date: 2017-03-16 09:51 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/9158f22042bb Merge - README - src/java.base/share/classes/java/lang/StackFramePermission.java Changeset: 7d8fe6923a14 Author: alexsch Date: 2017-03-16 23:29 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/7d8fe6923a14 8176883: Enable antialiasing for Metal L&F icons on HiDPI display Reviewed-by: prr ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java ! test/javax/swing/plaf/metal/MetalIcons/MetalHiDPIIconsTest.java Changeset: d9700e9006d0 Author: serb Date: 2017-03-16 22:03 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/d9700e9006d0 8160270: dual-screen issue with java.awt.Choice Reviewed-by: prr, alexsch ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuBarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XPopupMenuPeer.java ! test/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java + test/java/awt/PopupMenu/PopupMenuLocation.java Changeset: 4197c1ae4f47 Author: prr Date: 2017-03-21 08:48 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/4197c1ae4f47 Merge Changeset: 722952ece7ed Author: prr Date: 2017-03-21 09:53 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/722952ece7ed Merge Changeset: 81c76df23278 Author: skovalev Date: 2017-03-22 10:55 +0300 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/81c76df23278 8177324: Some javax/security/ tests don't have correct module dependencies Reviewed-by: weijun ! test/javax/security/auth/PrivateCredentialPermission/MoreThenOnePrincipals.java ! test/javax/security/auth/PrivateCredentialPermission/Subset.java ! test/javax/security/auth/Subject/Serial.java ! test/javax/security/auth/SubjectDomainCombiner/Regression.java + test/javax/security/auth/kerberos/TEST.properties ! test/javax/security/auth/login/Configuration/GetInstance.java ! test/javax/security/auth/login/Configuration/GetInstanceSecurity.java ! test/javax/security/auth/login/LoginContext/ConfigConstructor.java ! test/javax/security/auth/login/LoginContext/ConfigConstructorNoPerm.java ! test/javax/security/auth/login/LoginContext/ModuleSubject.java ! test/javax/security/sasl/Sasl/PassSysProps.java Changeset: b572f46f30cd Author: amlu Date: 2017-03-22 19:40 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b572f46f30cd 8177383: Wrong @modules in java/io/FilePermission/ReadFileOnPath.java Reviewed-by: alanb ! test/java/io/FilePermission/ReadFileOnPath.java ! test/java/lang/Package/annotation/PackageInfoTest.java ! test/java/lang/reflect/PublicMethods/PublicMethodsTest.java ! test/java/net/spi/URLStreamHandlerProvider/Basic.java ! test/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java Changeset: 085c764a3e5b Author: alanb Date: 2017-03-22 16:26 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/085c764a3e5b 8174823: Module system implementation refresh (3/2017) Reviewed-by: chegar, mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com, sundararajan.athijegannathan at oracle.com, peter.levart at gmail.com ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java - src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/Checks.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java + src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java + src/java.base/share/classes/jdk/internal/module/ModuleTarget.java ! src/java.base/share/classes/jdk/internal/module/Modules.java + src/java.base/share/classes/jdk/internal/module/Resources.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/native/libjava/ClassLoader.c ! src/java.base/share/native/libjava/Module.c ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ResourcePoolModule.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java + test/java/lang/ClassLoader/getResource/automaticmodules/Driver.java + test/java/lang/ClassLoader/getResource/automaticmodules/Main.java + test/java/lang/invoke/DefineClassTest.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java + test/java/lang/module/ModuleFinderWithSecurityManager.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java + test/java/lang/module/java.policy ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Module/allow.policy ! test/java/util/ServiceLoader/basic/basic.sh ! test/jdk/internal/jrtfs/java.policy + test/lib/testlibrary/ModuleTargetHelper.java ! test/sun/net/www/protocol/jrt/java.policy ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/CompiledVersionTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/p4/Main.java ! test/tools/launcher/modules/addexports/AddExportsTestWarningError.java ! test/tools/launcher/modules/addreads/AddReadsTestWarningError.java + test/tools/launcher/modules/basic/InitErrors.java ! test/tools/launcher/modules/patch/basic/PatchTestWarningError.java + test/tools/launcher/modules/permit/AttemptAccess.java + test/tools/launcher/modules/permit/PermitIllegalAccess.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: 0ca06091913f Author: alanb Date: 2017-03-22 18:41 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/0ca06091913f Merge ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/RuntimePermission.java - src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java Changeset: 443f9939b3b3 Author: jjg Date: 2017-03-23 11:42 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/443f9939b3b3 8176836: Provide Taglet with context Reviewed-by: ksrini ! make/src/classes/build/tools/taglet/Incubating.java Changeset: 7081836d4ceb Author: lana Date: 2017-03-23 22:57 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/7081836d4ceb Merge - src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java Changeset: 77ab8e3b4b04 Author: bpb Date: 2017-03-24 09:16 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/77ab8e3b4b04 8177550: (fc) Enable java/nio/channels/FileChannel/{Transfer4GBFile.java,TransferTo6GBFile.java} on Linux and Windows Summary: Re-enabled tests currently suppressed on Linux and Windows as the timeouts have been increased. Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Transfer4GBFile.java ! test/java/nio/channels/FileChannel/TransferTo6GBFile.java Changeset: 824789db6bea Author: alanb Date: 2017-03-24 16:35 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/824789db6bea 8177474: Do not emit warnings when illegal access is allowed by --add-exports/--add-opens Reviewed-by: chegar, mchung ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/modules/permit/PermitIllegalAccess.java Changeset: acd4fd0fd6e8 Author: bpb Date: 2017-03-24 14:46 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/acd4fd0fd6e8 8177564: Remove check for Windows XP and Server 2003 in java/nio/channels/DatagramChannel/NetworkConfiguration.java Summary: Remove check for XP and Server 2003 in IPv6 support determination. Reviewed-by: alanb ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java Changeset: 3bffd193a3a5 Author: bpb Date: 2017-03-24 15:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/3bffd193a3a5 8177565: java/nio/channels/Selector/SelectorLimit.java disabled for Windows release >= 6.0 Summary: Remove check of Windows version Reviewed-by: alanb ! test/java/nio/channels/Selector/SelectorLimit.java Changeset: fb54b256d751 Author: mchung Date: 2017-03-27 15:12 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/fb54b256d751 8174826: jlink support for linking in service provider modules Reviewed-by: alanb, anazarov ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Jlink.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLinkTest.java + test/tools/jlink/bindservices/BindServices.java + test/tools/jlink/bindservices/SuggestProviders.java + test/tools/jlink/bindservices/src/m1/module-info.java + test/tools/jlink/bindservices/src/m1/p1/Impl.java + test/tools/jlink/bindservices/src/m1/p1/Main.java + test/tools/jlink/bindservices/src/m1/p1/S.java + test/tools/jlink/bindservices/src/m2/module-info.java + test/tools/jlink/bindservices/src/m2/p2/Impl.java + test/tools/jlink/bindservices/src/m2/p2/T.java + test/tools/jlink/bindservices/src/m3/module-info.java + test/tools/jlink/bindservices/src/m3/p3/Impl.java Changeset: e685e3197f62 Author: darcy Date: 2017-03-27 18:38 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e685e3197f62 8177678: Overstatement of universality of Era.getDisplayName() implementation Reviewed-by: naoto ! src/java.base/share/classes/java/time/chrono/Era.java ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java Changeset: 50171f8c4796 Author: mli Date: 2017-03-27 18:52 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/50171f8c4796 8176865: overridden api has a wrong since value in java.base module Reviewed-by: alanb ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/nio/MappedByteBuffer.java ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! src/java.base/share/classes/java/security/SecureRandom.java ! src/java.base/share/classes/java/security/SecureRandomSpi.java Changeset: bd00098fc2d7 Author: lana Date: 2017-03-29 23:33 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/bd00098fc2d7 Added tag jdk-9+163 for changeset 50171f8c4796 ! .hgtags Changeset: 6efd46c87aff Author: bpb Date: 2017-03-28 09:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/6efd46c87aff 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 Summary: Enable test for macOS 10.10.5 and newer and remove from problem list Reviewed-by: alanb, amlu ! test/ProblemList.txt ! test/java/nio/channels/Selector/OutOfBand.java Changeset: c1207d6ce231 Author: darcy Date: 2017-03-28 17:33 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/c1207d6ce231 8177722: Improve grouping of jdk/internal/math tests Reviewed-by: smarks ! test/TEST.groups Changeset: 8903214706a2 Author: dfuchs Date: 2017-03-29 13:16 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/8903214706a2 8177136: Caller sensitive method System::getLogger should specify what happens if there is no caller on the stack. Summary: IllegalCallerException (instead of undocumented NPE) is thrown if there is no caller on the stack. The specification is clarified in this respect. Reviewed-by: alanb, mchung, dholmes, bchristi ! src/java.base/share/classes/java/lang/System.java Changeset: 171e10061798 Author: mchung Date: 2017-03-29 09:40 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/171e10061798 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea Contributed-by: jonathan.gibbons at oracle.com, mandy.chung at oracle.com ! make/GenerateModuleSummary.gmk ! make/ModuleTools.gmk ! make/src/classes/build/tools/jigsaw/GenGraphs.java + make/src/classes/build/tools/jigsaw/javadoc-graphs.properties + make/src/classes/build/tools/taglet/ModuleGraph.java ! src/java.base/share/classes/module-info.java ! src/java.datatransfer/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.instrument/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management.rmi/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.crypto.ec/share/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.ucrypto/solaris/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jsobject/share/classes/module-info.java ! src/jdk.jstatd/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.management.agent/share/classes/module-info.java ! src/jdk.management/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.net/share/classes/module-info.java ! src/jdk.sctp/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java Changeset: 10e27f8fa3a1 Author: ksrini Date: 2017-03-29 10:50 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/10e27f8fa3a1 8174148: Typo in java.util.jar.Pack200.Unpacker.properties() method documentation 8173871: Typos in Jar Packer/Unpacker PROGRESS field documentation Reviewed-by: bpb, darcy ! src/java.base/share/classes/java/util/jar/Pack200.java Changeset: b79469412aa0 Author: weijun Date: 2017-03-30 07:29 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b79469412aa0 8177569: keytool should not warn if signature algorithm used in cacerts is weak Reviewed-by: mullan ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! test/sun/security/tools/keytool/WeakAlg.java Changeset: 5734c4a761cf Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/5734c4a761cf Merge Changeset: a1d25a8fdc98 Author: smarks Date: 2017-03-30 11:26 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/a1d25a8fdc98 8155052: add notes and links to j.u.Observer/Observable deprecation comments Reviewed-by: chegar ! src/java.base/share/classes/java/util/Observable.java Changeset: 762c970fed4d Author: rehn Date: 2017-03-16 07:27 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/762c970fed4d 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool Reviewed-by: sspitsyn, dsamersoff ! src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java ! src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java Changeset: 13c06d444258 Author: iignatyev Date: 2017-03-15 22:48 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/13c06d444258 8176176: fix @modules in jdk_svc tests Reviewed-by: shurailine, sspitsyn ! test/com/sun/jdi/AcceptTimeout.java ! test/com/sun/jdi/AccessSpecifierTest.java ! test/com/sun/jdi/AfterThreadDeathTest.java ! test/com/sun/jdi/AllLineLocations.java ! test/com/sun/jdi/ArrayRangeTest.java ! test/com/sun/jdi/BacktraceFieldTest.java ! test/com/sun/jdi/ClassLoaderClassesTest.java ! test/com/sun/jdi/ClassesByName.java ! test/com/sun/jdi/ClassesByName2Test.java ! test/com/sun/jdi/CompatibleConnectors.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/ConstantPoolInfo.java ! test/com/sun/jdi/ConstantPoolInfoGC.java ! test/com/sun/jdi/CountEvent.java ! test/com/sun/jdi/CountFilterTest.java ! test/com/sun/jdi/DebuggerThreadTest.java ! test/com/sun/jdi/DeleteAllBkptsTest.java ! test/com/sun/jdi/DeleteEventRequestsTest.java ! test/com/sun/jdi/EarlyReturnNegativeTest.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/EnumTest.java ! test/com/sun/jdi/EventQueueDisconnectTest.java ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/ExpiredRequestDeletionTest.java ! test/com/sun/jdi/FieldWatchpoints.java ! test/com/sun/jdi/FilterMatch.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/FinalLocalsTest.java ! test/com/sun/jdi/FinalizerTest.java ! test/com/sun/jdi/FramesTest.java ! test/com/sun/jdi/GenericsTest.java ! test/com/sun/jdi/GetLocalVariables2Test.java ! test/com/sun/jdi/GetUninitializedStringValue.java ! test/com/sun/jdi/HomeTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/InstanceFilter.java ! test/com/sun/jdi/InstancesTest.java ! test/com/sun/jdi/InterfaceMethodsTest.java ! test/com/sun/jdi/InterruptHangTest.java ! test/com/sun/jdi/InvokeHangTest.java ! test/com/sun/jdi/InvokeTest.java ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/Java_gTest.java ! test/com/sun/jdi/LambdaStepTest.java ! test/com/sun/jdi/LaunchCommandLine.java ! test/com/sun/jdi/LineNumberInfo.java ! test/com/sun/jdi/ListenAddress.java ! test/com/sun/jdi/LocalVariableEqual.java ! test/com/sun/jdi/LocationTest.java ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/MixedSuspendTest.sh ! test/com/sun/jdi/ModificationWatchpoints.java ! test/com/sun/jdi/ModulesTest.java ! test/com/sun/jdi/MonitorEventTest.java ! test/com/sun/jdi/MonitorFrameInfo.java ! test/com/sun/jdi/MultiBreakpointsTest.java ! test/com/sun/jdi/NativeInstanceFilter.java ! test/com/sun/jdi/NewInstanceTest.java ! test/com/sun/jdi/NoLaunchOptionTest.java ! test/com/sun/jdi/NoLocInfoTest.java ! test/com/sun/jdi/NullThreadGroupNameTest.java ! test/com/sun/jdi/OnThrowTest.java ! test/com/sun/jdi/OptionTest.java ! test/com/sun/jdi/PopAndInvokeTest.java ! test/com/sun/jdi/PopAsynchronousTest.java ! test/com/sun/jdi/PopSynchronousTest.java ! test/com/sun/jdi/RedefineCrossEvent.java ! test/com/sun/jdi/RedefineCrossStart.java ! test/com/sun/jdi/ReferrersTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/RequestReflectionTest.java ! test/com/sun/jdi/ResumeOneThreadTest.java ! test/com/sun/jdi/SDENullTest.java ! test/com/sun/jdi/SimulResumerTest.java ! test/com/sun/jdi/SourceNameFilterTest.java ! test/com/sun/jdi/StepTest.java ! test/com/sun/jdi/SuspendThreadTest.java + test/com/sun/jdi/TEST.properties ! test/com/sun/jdi/TemplateTest.java ! test/com/sun/jdi/ThreadGroupTest.java ! test/com/sun/jdi/TwoThreadsTest.java ! test/com/sun/jdi/UTF8Test.java ! test/com/sun/jdi/UnpreparedByName.java ! test/com/sun/jdi/UnpreparedClasses.java ! test/com/sun/jdi/VMDeathLastTest.java ! test/com/sun/jdi/VMDeathRequestTest.java ! test/com/sun/jdi/VarargsTest.java ! test/com/sun/jdi/Vars.java ! test/com/sun/jdi/VisibleMethods.java ! test/com/sun/jdi/connect/spi/GeneratedConnectors.java ! test/com/sun/jdi/redefine/RedefineTest.java ! test/com/sun/jdi/redefineMethod/RedefineTest.java ! test/com/sun/jdi/sde/FilterMangleTest.java ! test/com/sun/jdi/sde/MangleStepTest.java ! test/com/sun/jdi/sde/MangleTest.java ! test/com/sun/jdi/sde/SourceDebugExtensionTest.java ! test/com/sun/jdi/sde/TemperatureTableTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java ! test/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDoubleVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetAllVMOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java ! test/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/GetFreePhysicalMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/GetFreeSwapSpaceSize.java ! test/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java ! test/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java ! test/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java ! test/com/sun/management/OperatingSystemMXBean/GetTotalPhysicalMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/MemoryStatusOverflow.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.java + test/com/sun/management/TEST.properties ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java ! test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/management/VMOptionOpenDataTest.java ! test/com/sun/tools/attach/PermissionTest.java ! test/com/sun/tools/attach/ProviderTest.java ! test/com/sun/tools/attach/StartManagementAgent.java ! test/com/sun/tools/attach/TempDirTest.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/instrument/TestAgentWithLimitMods.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/management/CompositeData/MemoryUsageCompositeData.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/GetObjectName.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/GetPlatformManagementInterfaces.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/MXBeanException.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/ManagementFactory/PlatformMBeanServerTest.java ! test/java/lang/management/ManagementFactory/ProxyExceptions.java ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java + test/java/lang/management/ManagementFactory/TEST.properties ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh ! test/java/lang/management/MemoryMXBean/MemoryManagementConcMarkSweepGC.sh ! test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh ! test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh ! test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh + test/java/lang/management/PlatformLoggingMXBean/TEST.properties ! test/java/lang/management/RuntimeMXBean/GetSystemProperties.java ! test/java/lang/management/RuntimeMXBean/PropertiesTest.java ! test/java/lang/management/RuntimeMXBean/TestInputArgument.sh ! test/java/lang/management/RuntimeMXBean/UpTime.java + test/java/lang/management/TEST.properties ! test/java/lang/management/ThreadMXBean/AllThreadIds.java ! test/java/lang/management/ThreadMXBean/DisableTest.java ! test/java/lang/management/ThreadMXBean/EnableTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/FindMonitorDeadlock.java ! test/java/lang/management/ThreadMXBean/InvalidThreadID.java ! test/java/lang/management/ThreadMXBean/LockedMonitors.java ! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java ! test/java/lang/management/ThreadMXBean/ResetPeakThreadCount.java ! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java ! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java ! test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java ! test/java/lang/management/ThreadMXBean/ThreadCounts.java ! test/java/lang/management/ThreadMXBean/ThreadCpuTime.java ! test/java/lang/management/ThreadMXBean/ThreadDaemonTest.java ! test/java/lang/management/ThreadMXBean/ThreadLists.java ! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java ! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java ! test/java/lang/management/ThreadMXBean/ThreadUserTime.java ! test/javax/management/ImplementationVersion/ImplVersionTest.java ! test/javax/management/Introspector/AnnotationSecurityTest.java ! test/javax/management/Introspector/AnnotationTest.java ! test/javax/management/Introspector/ChangingNotifsTest.java ! test/javax/management/Introspector/ClassLeakTest.java ! test/javax/management/Introspector/DuplicateGetterTest.java ! test/javax/management/Introspector/FeatureOrderTest.java ! test/javax/management/Introspector/GetMBeanInfoExceptionTest.java ! test/javax/management/Introspector/IdenticalMBeanInfoTest.java ! test/javax/management/Introspector/ImmutableNotificationInfoTest.java ! test/javax/management/Introspector/InvokeGettersTest.java ! test/javax/management/Introspector/IsMethodTest.java ! test/javax/management/Introspector/LegacyConstructorPropertiesTest.java ! test/javax/management/Introspector/NotAnMBeanTest.java ! test/javax/management/Introspector/NotCompliantCauseTest.java ! test/javax/management/Introspector/SetWrongTypeAttributeTest.java ! test/javax/management/Introspector/UnregisterMBeanExceptionTest.java ! test/javax/management/MBeanInfo/EqualExceptionTest.java ! test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java ! test/javax/management/MBeanInfo/MBeanInfoEqualsTest.java ! test/javax/management/MBeanInfo/MBeanInfoHashCodeNPETest.java ! test/javax/management/MBeanInfo/NullInfoArraysTest.java ! test/javax/management/MBeanInfo/SerializationTest.java ! test/javax/management/MBeanInfo/SerializationTest1.java ! test/javax/management/MBeanInfo/TooManyFooTest.java ! test/javax/management/MBeanServer/AttributeListTypeSafeTest.java ! test/javax/management/MBeanServer/MBeanExceptionTest.java ! test/javax/management/MBeanServer/MBeanFallbackTest.java ! test/javax/management/MBeanServer/MBeanServerInvocationHandlerExceptionTest.java ! test/javax/management/MBeanServer/MBeanTest.java ! test/javax/management/MBeanServer/NewMBeanListenerTest.java ! test/javax/management/MBeanServer/NotifDeadlockTest.java ! test/javax/management/MBeanServer/PostExceptionTest.java ! test/javax/management/MBeanServer/PostRegisterDeadlockTest.java ! test/javax/management/MBeanServer/PostRegisterDeadlockTest2.java ! test/javax/management/MBeanServer/PreDeregisterDeadlockTest.java ! test/javax/management/MBeanServer/PreRegisterTest.java ! test/javax/management/MBeanServerFactory/ReleaseMBeanServerTest.java ! test/javax/management/MustBeValidMBeanInfo/MustBeValidCommand.java ! test/javax/management/ObjectInstance/MBeanInfoFailTest.java ! test/javax/management/ObjectInstance/ObjectInstanceNullTest.java ! test/javax/management/ObjectInstance/ToStringMethodTest.java ! test/javax/management/ObjectName/ApplyWildcardTest.java ! test/javax/management/ObjectName/ComparatorTest.java ! test/javax/management/ObjectName/DelegateNameWildcardNameTest.java ! test/javax/management/ObjectName/NullEmptyKeyValueTest.java ! test/javax/management/ObjectName/ObjectNameGetInstanceTest.java ! test/javax/management/ObjectName/RepositoryWildcardTest.java ! test/javax/management/ObjectName/SerialCompatTest.java ! test/javax/management/ObjectName/ValueWildcardTest.java + test/javax/management/TEST.properties ! test/javax/management/descriptor/DefaultDescriptorTest.java ! test/javax/management/descriptor/DescriptorTest.java ! test/javax/management/descriptor/EqualsHashCodeTest.java ! test/javax/management/descriptor/ImmutableArrayFieldTest.java ! test/javax/management/descriptor/ImmutableDescriptorSerialTest.java ! test/javax/management/descriptor/ImmutableDescriptorSetFieldsTest.java ! test/javax/management/descriptor/MBeanInfoInteropTest.java ! test/javax/management/descriptor/UnionTest.java ! test/javax/management/generified/GenericTest.java ! test/javax/management/generified/ListTypeCheckTest.java ! test/javax/management/loading/ArrayClassTest.java ! test/javax/management/loading/DocumentRootTest.java ! test/javax/management/loading/GetMBeansFromURLTest.java ! test/javax/management/loading/LibraryLoader/LibraryLoaderTest.java ! test/javax/management/loading/MLetCLR/MLetCommand.java ! test/javax/management/loading/MLetContentTest.java ! test/javax/management/loading/MletParserLocaleTest.java ! test/javax/management/loading/ParserInfiniteLoopTest.java ! test/javax/management/loading/SystemClassLoaderTest.java ! test/javax/management/modelmbean/AddAttributeChangeNotificationListenerTest.java ! test/javax/management/modelmbean/DescriptorSupportSerialTest.java ! test/javax/management/modelmbean/DescriptorSupportTest.java ! test/javax/management/modelmbean/DescriptorSupportXMLLocaleTest.java ! test/javax/management/modelmbean/DescriptorSupportXMLTest.java ! test/javax/management/modelmbean/ExoticTargetTypeTest.java ! test/javax/management/modelmbean/InfoSupportTest.java ! test/javax/management/modelmbean/LoggingExceptionTest.java ! test/javax/management/modelmbean/ModelMBeanInfoSupport/GetAllDescriptorsTest.java ! test/javax/management/modelmbean/OnUnregisterTest.java ! test/javax/management/modelmbean/RequiredModelMBeanGetAttributeTest.java ! test/javax/management/modelmbean/RequiredModelMBeanMethodTest.java ! test/javax/management/modelmbean/RequiredModelMBeanSetAttributeTest.java ! test/javax/management/modelmbean/SimpleModelMBean/SimpleModelMBeanCommand.java ! test/javax/management/monitor/CounterMonitorDeadlockTest.java ! test/javax/management/monitor/CounterMonitorInitThresholdTest.java ! test/javax/management/monitor/CounterMonitorTest.java ! test/javax/management/monitor/CounterMonitorThresholdTest.java ! test/javax/management/monitor/DerivedGaugeMonitorTest.java ! test/javax/management/monitor/GaugeMonitorDeadlockTest.java ! test/javax/management/monitor/MultiMonitorTest.java ! test/javax/management/monitor/NonComparableAttributeValueTest.java ! test/javax/management/monitor/NullAttributeValueTest.java ! test/javax/management/monitor/ReflectionExceptionTest.java ! test/javax/management/monitor/RuntimeExceptionTest.java ! test/javax/management/monitor/StartStopTest.java ! test/javax/management/monitor/StringMonitorDeadlockTest.java ! test/javax/management/monitor/ThreadPoolAccTest.java ! test/javax/management/monitor/ThreadPoolTest.java ! test/javax/management/mxbean/AmbiguousConstructorTest.java ! test/javax/management/mxbean/ComparatorExceptionTest.java ! test/javax/management/mxbean/ExceptionDiagnosisTest.java ! test/javax/management/mxbean/GenericTypeTest.java ! test/javax/management/mxbean/InvalidMXBeanRegistrationTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MBeanOperationInfoTest.java ! test/javax/management/mxbean/MXBeanAnnotationTest.java ! test/javax/management/mxbean/MXBeanFallbackTest.java ! test/javax/management/mxbean/MXBeanFlagTest.java ! test/javax/management/mxbean/MXBeanLoadingTest1.java ! test/javax/management/mxbean/MXBeanPreRegisterTest.java ! test/javax/management/mxbean/MXBeanRefTest.java ! test/javax/management/mxbean/MiscTest.java ! test/javax/management/mxbean/OperationImpactTest.java ! test/javax/management/mxbean/OverloadTest.java ! test/javax/management/mxbean/PreRegisterNameTest.java ! test/javax/management/mxbean/PropertyNamesTest.java ! test/javax/management/mxbean/SameObjectTwoNamesTest.java ! test/javax/management/mxbean/StandardMBeanOverrideTest.java ! test/javax/management/mxbean/ThreadMXBeanTest.java ! test/javax/management/mxbean/TypeNameTest.java ! test/javax/management/notification/BroadcasterSupportDeadlockTest.java ! test/javax/management/notification/FilterExceptionTest.java ! test/javax/management/notification/NotifExecutorTest.java ! test/javax/management/notification/NotifInfoTest.java ! test/javax/management/openmbean/ArrayTypeTest.java ! test/javax/management/openmbean/BadConstraintTest.java ! test/javax/management/openmbean/CompositeDataStringTest.java ! test/javax/management/openmbean/ConstraintTest.java ! test/javax/management/openmbean/EqualsTest.java ! test/javax/management/openmbean/IsValueTest.java ! test/javax/management/openmbean/NullConstructorParamsTest.java ! test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java ! test/javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java ! test/javax/management/openmbean/OpenTypeDescriptorTest.java ! test/javax/management/proxy/JMXProxyFallbackTest.java ! test/javax/management/proxy/JMXProxyTest.java ! test/javax/management/proxy/NotificationEmitterProxy.java ! test/javax/management/proxy/ProxyObjectMethodsTest.java ! test/javax/management/query/CustomQueryTest.java ! test/javax/management/query/InstanceOfExpTest.java ! test/javax/management/query/QueryExpStringTest.java ! test/javax/management/query/QueryMatchTest.java ! test/javax/management/query/QuerySubstringTest.java ! test/javax/management/relation/NonArrayListTest.java ! test/javax/management/relation/RelationNotificationSeqNoTest.java ! test/javax/management/relation/RelationNotificationSourceTest.java ! test/javax/management/relation/RelationTypeTest.java + test/javax/management/remote/mandatory/TEST.properties ! test/javax/management/remote/mandatory/URLTest.java ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java ! test/javax/management/remote/mandatory/connection/CloseFailedClientTest.java ! test/javax/management/remote/mandatory/connection/CloseServerTest.java ! test/javax/management/remote/mandatory/connection/CloseUnconnectedTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.java ! test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java ! test/javax/management/remote/mandatory/connection/DeadLockTest.java ! test/javax/management/remote/mandatory/connection/FailedConnectionTest.java ! test/javax/management/remote/mandatory/connection/GetConnectionTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/JMXServiceURLLocaleTest.java ! test/javax/management/remote/mandatory/connection/MultiOpenCloseTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorLogAttributesTest.java ! test/javax/management/remote/mandatory/connection/RMIExitTest.java ! test/javax/management/remote/mandatory/connection/RMISerializeTest.java ! test/javax/management/remote/mandatory/connection/ReconnectTest.java ! test/javax/management/remote/mandatory/connectorServer/ConnectorStopDeadlockTest.java ! test/javax/management/remote/mandatory/connectorServer/JNDIFailureTest.java ! test/javax/management/remote/mandatory/connectorServer/MBSFPreStartPostStartTest.java ! test/javax/management/remote/mandatory/loading/DefaultProviderTest.java ! test/javax/management/remote/mandatory/loading/DeserializeEncodedURLTest.java ! test/javax/management/remote/mandatory/loading/MethodResultTest.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/loading/RMIDownloadTest.java ! test/javax/management/remote/mandatory/loading/TargetMBeanTest.java ! test/javax/management/remote/mandatory/loading/UserClassLoaderTest.java ! test/javax/management/remote/mandatory/notif/AddRemoveTest.java ! test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java ! test/javax/management/remote/mandatory/notif/DiffHBTest.java ! test/javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java ! test/javax/management/remote/mandatory/notif/NotifBufferSizePropertyNameTest.java ! test/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferCreationTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/javax/management/remote/mandatory/notif/RMINotifTest.java ! test/javax/management/remote/mandatory/notif/ServerNotifs.java ! test/javax/management/remote/mandatory/notif/UnexpectedNotifTest.java ! test/javax/management/remote/mandatory/passwordAccessFile/NonJMXPrincipalsTest.java ! test/javax/management/remote/mandatory/passwordAccessFile/PasswordAccessFileTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java ! test/javax/management/remote/mandatory/threads/ExecutorShutdownTest.java ! test/javax/management/remote/mandatory/threads/ExecutorTest.java ! test/javax/management/remote/mandatory/threads/NoServerTimeoutTest.java ! test/javax/management/remote/mandatory/version/ImplVersionTest.java ! test/javax/management/security/AvoidGetMBeanInfoCallsTest.java ! test/javax/management/security/MBeanPermissionTest.java ! test/javax/management/standardmbean/DeadlockTest.java ! test/javax/management/timer/MissingNotificationTest.java ! test/javax/management/timer/StartTest.java + test/sun/jvmstat/TEST.properties ! test/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/jvmstat/monitor/VmIdentifier/VmIdentifierCreateResolve.java ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java ! test/sun/management/LazyCompositeDataTest.java ! test/sun/management/LoggingTest/LoggingWithJULTest.java ! test/sun/management/LoggingTest/LoggingWithLoggerFinderTest.java ! test/sun/management/StackTraceElementCompositeData/CompatibilityTest.java + test/sun/management/TEST.properties ! test/sun/management/jdp/JdpDefaultsTest.java ! test/sun/management/jdp/JdpJmxRemoteDynamicPortTest.java ! test/sun/management/jdp/JdpOffTest.java ! test/sun/management/jdp/JdpSpecificAddressTest.java + test/sun/management/jdp/TEST.properties ! test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java + test/sun/management/jmxremote/TEST.properties ! test/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/management/jmxremote/startstop/JMXStatusTest.java + test/sun/tools/jcmd/TEST.properties ! test/sun/tools/jcmd/TestJcmdDefaults.java ! test/sun/tools/jcmd/TestJcmdSanity.java ! test/sun/tools/jconsole/ResourceCheckTest.java + test/sun/tools/jhsdb/TEST.properties ! test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java ! test/sun/tools/jinfo/JInfoTest.java + test/sun/tools/jinfo/TEST.properties + test/sun/tools/jmap/TEST.properties + test/sun/tools/jstack/TEST.properties + test/sun/tools/jstat/TEST.properties + test/sun/tools/jstatd/TEST.properties ! test/sun/tools/jstatd/TestJstatdDefaults.java ! test/sun/tools/jstatd/TestJstatdExternalRegistry.java ! test/sun/tools/jstatd/TestJstatdPort.java ! test/sun/tools/jstatd/TestJstatdPortAndServer.java ! test/sun/tools/jstatd/TestJstatdServer.java Changeset: 63545defbee3 Author: jwilhelm Date: 2017-03-20 23:49 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/63545defbee3 Merge Changeset: 2d00e12c474d Author: iignatyev Date: 2017-03-22 17:57 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/2d00e12c474d 8177374: fix module dependency declaration in jdk_svc tests Reviewed-by: mchung, sspitsyn ! test/com/sun/tools/attach/BasicTests.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java Changeset: e42aa54d7ed7 Author: jwilhelm Date: 2017-03-23 15:06 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e42aa54d7ed7 Merge Changeset: b45f8cb93c6f Author: jwilhelm Date: 2017-03-25 00:31 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b45f8cb93c6f Merge Changeset: eeffca2a1db2 Author: jwilhelm Date: 2017-03-30 19:55 +0200 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/eeffca2a1db2 Merge Changeset: b23f0d9ff042 Author: jwilhelm Date: 2017-03-30 21:02 +0200 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/b23f0d9ff042 Merge Changeset: 184445e67dc7 Author: sherman Date: 2017-03-31 11:33 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/184445e67dc7 8177910: Update zlib copyright note in idk/src/java.base/share/legal/zlib.md Reviewed-by: mchung, rriggs ! src/java.base/share/legal/zlib.md Changeset: 7c72114a5558 Author: smarks Date: 2017-03-31 14:21 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/7c72114a5558 8177653: clarify restrictions on Iterator.forEachRemaining Reviewed-by: martin ! src/java.base/share/classes/java/util/Iterator.java Changeset: f2612af45b7a Author: amlu Date: 2017-04-01 10:19 +0800 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/f2612af45b7a 8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.groups Reviewed-by: sspitsyn, weijun ! test/ProblemList.txt ! test/TEST.groups Changeset: 6dea581453d7 Author: dfuchs Date: 2017-04-03 12:54 +0100 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/6dea581453d7 8177835: System.LoggerFinder#getLogger or getLocalizedLogger does not throw NPE Reviewed-by: rriggs, mchung ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java + test/java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java Changeset: c779133005cf Author: lana Date: 2017-04-06 04:53 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/c779133005cf Merge ! .hgtags - src/java.base/macosx/native/launcher/jexec.c ! src/java.base/share/classes/java/lang/System.java - src/java.base/unix/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java Changeset: 4cab82804a44 Author: mullan Date: 2017-04-06 16:21 -0400 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/4cab82804a44 8161973: PKIXRevocationChecker.getSoftFailExceptions() not working Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java ! test/javax/net/ssl/Stapling/SSLSocketWithStapling.java Changeset: 645c0d3e3977 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/645c0d3e3977 Added tag jdk-9+164 for changeset 6dea581453d7 ! .hgtags Changeset: 37f8b938b680 Author: lana Date: 2017-04-08 03:25 +0000 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/37f8b938b680 Merge ! .hgtags - src/java.base/macosx/native/launcher/jexec.c - src/java.base/unix/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java Changeset: 1f0fb30f5279 Author: dl Date: 2017-04-10 13:46 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/1f0fb30f5279 8176402: parameter name switcharoo in ConcurrentHashMap Reviewed-by: martin, psandoz ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 8cd9c45a2802 Author: dl Date: 2017-04-10 13:46 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/8cd9c45a2802 8176543: Miscellaneous changes imported from jsr166 CVS 2017-04 Reviewed-by: martin, psandoz ! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! test/java/util/concurrent/tck/ArrayDeque8Test.java ! test/java/util/concurrent/tck/ArrayDequeTest.java ! test/java/util/concurrent/tck/ArrayListTest.java ! test/java/util/concurrent/tck/AtomicReferenceFieldUpdaterTest.java ! test/java/util/concurrent/tck/AtomicReferenceTest.java ! test/java/util/concurrent/tck/CompletableFutureTest.java ! test/java/util/concurrent/tck/ConcurrentHashMap8Test.java ! test/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/java/util/concurrent/tck/ConcurrentLinkedQueueTest.java ! test/java/util/concurrent/tck/ConcurrentSkipListSetTest.java ! test/java/util/concurrent/tck/ConcurrentSkipListSubSetTest.java ! test/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/java/util/concurrent/tck/CountedCompleter8Test.java ! test/java/util/concurrent/tck/CountedCompleterTest.java ! test/java/util/concurrent/tck/ExchangerTest.java ! test/java/util/concurrent/tck/ExecutorCompletionService9Test.java ! test/java/util/concurrent/tck/ExecutorCompletionServiceTest.java ! test/java/util/concurrent/tck/ExecutorsTest.java ! test/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/java/util/concurrent/tck/ForkJoinPool9Test.java ! test/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/java/util/concurrent/tck/JSR166TestCase.java ! test/java/util/concurrent/tck/LinkedBlockingDeque8Test.java ! test/java/util/concurrent/tck/LinkedBlockingDequeTest.java ! test/java/util/concurrent/tck/LinkedBlockingQueue8Test.java ! test/java/util/concurrent/tck/LinkedBlockingQueueTest.java ! test/java/util/concurrent/tck/LinkedListTest.java ! test/java/util/concurrent/tck/LinkedTransferQueueTest.java ! test/java/util/concurrent/tck/PriorityBlockingQueueTest.java ! test/java/util/concurrent/tck/PriorityQueueTest.java ! test/java/util/concurrent/tck/RecursiveActionTest.java ! test/java/util/concurrent/tck/RecursiveTaskTest.java ! test/java/util/concurrent/tck/StampedLockTest.java ! test/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/java/util/concurrent/tck/SynchronousQueueTest.java ! test/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java ! test/java/util/concurrent/tck/ThreadPoolExecutorTest.java ! test/java/util/concurrent/tck/ThreadTest.java ! test/java/util/concurrent/tck/TreeSetTest.java ! test/java/util/concurrent/tck/TreeSubSetTest.java ! test/java/util/concurrent/tck/VectorTest.java From mikael.vidstedt at oracle.com Tue Apr 11 21:24:24 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 14:24:24 -0700 Subject: Welcome to Portola! Message-ID: <6982BDF9-5229-476A-9E0E-98DCB2F78CE9@oracle.com> All, Welcome to the Portola project! From the CFV: "This Project will provide a port of the JDK to the Alpine Linux distribution, and in particular the "musl" C library.? I have done some initial work getting the JDK to build and run on musl. Over the next few days I will work on getting those changes pushed to the portola/portola forest[1], which is based on jdk10/jdk10 [2]. I updated the portola forest from jdk10 yesterday. In total I have around 15 changes, which come in roughly the following flavors: * JDK build system support (~5 changes) * Straightforward/trivial code changes (~8 changes) * Actual bug fixes/slightly more involved changes (~2 changes) Note: I?m not planning on pushing these changes in any particular order, they?re all needed for a successful/working JDK. You will find that most of the code changes are not musl specific. Rather, they are effectively adjusting the existing code to be more portable. There is one notable exceptions to this, which I?ll describe more in the corresponding RFR. The Portola project is set up to use the ?commit first, review later? policy, meaning the changes are *not* expected to go into the JDK repositories without some additional polishing work. That said, my plan is to push the change *and* send out a corresponding review email *in parallel*. Please help me review the changes and verifying their sanity. When needed, based on reviews/feedback/etc., additional changes can be made. Let me know if you have any questions, and please help me with the reviews! Cheers, Mikael [1] http://hg.openjdk.java.net/portola/portola [2] http://hg.openjdk.java.net/jdk10/jdk10/ From mikael.vidstedt at oracle.com Tue Apr 11 22:42:32 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 15:42:32 -0700 Subject: RFR: Remove sys/ prefix from poll.h/signal.h includes Message-ID: <3724BBC4-5016-495A-A4CA-3FD8E6F2A375@oracle.com> In several places in the JDK sources poll.h and signal.h are included through sys/{poll.h,signal.h}. The posix spec says the files should be included without the sys/ prefix, and musl issues a warning when sys/{poll.h,signal.h} are included. This change simple removes the sys/ prefix in all the relevant places. I?ve tried my best to verify that this works on all the platforms/toolchains I have access to, and also got help from the SAP guys to verify that it should work on AIX as well. hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/pollsignal/webrev.00/hotspot/webrev/ jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/pollsignal/webrev.00/jdk/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Tue Apr 11 22:48:00 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 22:48:00 +0000 Subject: hg: portola/portola/hotspot: Remove sys/ prefix from poll.h/signal.h includes Message-ID: <201704112248.v3BMm0JF004232@aojmv0008.oracle.com> Changeset: 95d3f5d5ca24 Author: mikael Date: 2017-04-11 15:44 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/95d3f5d5ca24 Remove sys/ prefix from poll.h/signal.h includes ! src/os/aix/vm/os_aix.inline.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp From mikael.vidstedt at oracle.com Tue Apr 11 22:48:09 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 22:48:09 +0000 Subject: hg: portola/portola/jdk: Remove sys/ prefix from poll.h/signal.h includes Message-ID: <201704112248.v3BMmAfd004375@aojmv0008.oracle.com> Changeset: e5f4488e151b Author: mikael Date: 2017-04-11 15:45 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/e5f4488e151b Remove sys/ prefix from poll.h/signal.h includes ! src/java.base/aix/native/libnet/aix_close.c ! src/java.base/aix/native/libnio/ch/AixPollPort.c ! src/java.base/linux/native/libnet/linux_close.c ! src/java.base/linux/native/libnio/fs/LinuxWatchService.c ! src/java.base/macosx/native/include/jvm_md.h ! src/java.base/macosx/native/libnet/bsd_close.c ! src/java.base/solaris/native/libnio/ch/DevPollArrayWrapper.c ! src/java.base/unix/native/include/jvm_md.h ! src/java.base/unix/native/libnet/net_util_md.h ! src/java.base/unix/native/libnio/ch/NativeThread.c ! src/java.base/unix/native/libnio/ch/Net.c ! src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c From mikael.vidstedt at oracle.com Tue Apr 11 23:04:41 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 16:04:41 -0700 Subject: RFR: Use isnan instead of isnanf Message-ID: <88A94D3B-AE97-42BB-8F90-34EF1E6B316F@oracle.com> isnanf is not available in musl. posix says that isnan handles both float and double arguments (typically through a macro checking the size of the operand and delegation to the corresponding/actual isnan primitive). This change makes the two JDK wrapper macros call isnan instead of isnanf. I?ve tried to verify that the toolchains I have access to does the Right(tm) thing for float, but additional verification/testing is probably warranted before this is ?productized?. hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/hotspot/webrev/ jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/jdk/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Tue Apr 11 23:07:17 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 23:07:17 +0000 Subject: hg: portola/portola/hotspot: Use isnan instead of isnanf Message-ID: <201704112307.v3BN7HLr017051@aojmv0008.oracle.com> Changeset: b643cbade748 Author: mikael Date: 2017-04-11 16:04 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/b643cbade748 Use isnan instead of isnanf ! src/share/vm/utilities/globalDefinitions_gcc.hpp From mikael.vidstedt at oracle.com Tue Apr 11 23:07:26 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 23:07:26 +0000 Subject: hg: portola/portola/jdk: Use isnan instead of isnanf Message-ID: <201704112307.v3BN7QYT017222@aojmv0008.oracle.com> Changeset: 7ff9f3e84585 Author: mikael Date: 2017-04-11 16:04 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/7ff9f3e84585 Use isnan instead of isnanf ! src/java.base/unix/native/libjava/jdk_util_md.h From mikael.vidstedt at oracle.com Tue Apr 11 23:14:32 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 16:14:32 -0700 Subject: RFR: Add limited support for -musl to config.sub Message-ID: The version of autoconfig-config.sub checked into the JDK repo is old enough to not support/handle musl. This change adds (very) limited support for handling musl tuples. Specifically, it *only* handles the exact tuple 'x86_64-unknown-linux-musl' and handles it by returning the exact same tuple string. This clearly needs to be made more flexible going forward, and I?m following up on options to do so. Meanwhile, this at least works well enough to get something building. http://cr.openjdk.java.net/~mikael/webrevs/portola/configsub/webrev.00/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Tue Apr 11 23:16:03 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 23:16:03 +0000 Subject: hg: portola/portola: Add limited support for musl to config.sub Message-ID: <201704112316.v3BNG4dm018900@aojmv0008.oracle.com> Changeset: 3441a52c7922 Author: mikael Date: 2017-04-11 16:14 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/3441a52c7922 Add limited support for musl to config.sub ! common/autoconf/build-aux/config.sub From mikael.vidstedt at oracle.com Tue Apr 11 23:23:48 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 16:23:48 -0700 Subject: RFR: Remove execinfo debug code from XToolkit.c Message-ID: <4C391CDA-715A-48DE-87A9-41DEDE6ECB93@oracle.com> XToolkit.c has some linux specific debug code in it which is effectively dead. The debug code depends on backtracing functionality from execinfo.h, but musl does not implement/support execinfo.h. Since the code is dead, I chose to remove it. In case it turns out that this debugging code gets used a lot when chasing down bugs etc. we?ll have to look at how to support it on musl, or perhaps only enable it if execinfo.h is available. http://cr.openjdk.java.net/~mikael/webrevs/portola/execinfo/webrev.00/jdk/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Tue Apr 11 23:26:05 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 23:26:05 +0000 Subject: hg: portola/portola/jdk: Remove execinfo.h debug code from XToolkit.c Message-ID: <201704112326.v3BNQ5QP022208@aojmv0008.oracle.com> Changeset: 058da8d0c93d Author: mikael Date: 2017-04-11 16:23 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/058da8d0c93d Remove execinfo.h debug code from XToolkit.c ! src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c From mikael.vidstedt at oracle.com Tue Apr 11 23:46:19 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 16:46:19 -0700 Subject: RFR: Only include fpu_control.h on 32-bit x86 Message-ID: <9F64D3DF-76B0-41EB-94EF-A4255CBEA750@oracle.com> os_linux_x86_.cpp has some code to set/update/tickle the fpu control word. The code makes use of functions from the fpu_control.h header, but is only used on 32-bit x86. musl doesn?t have the fpu_control.h header file. This change adds a conditional include guard to only include the fpu_control.h on 32-bit x86 (!AMD64), which matches the guards used in the places further down in the file where the functionality is actually used. http://cr.openjdk.java.net/~mikael/webrevs/portola/fpucontrol/webrev.00/hotspot/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Tue Apr 11 23:49:15 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 11 Apr 2017 23:49:15 +0000 Subject: hg: portola/portola/hotspot: Only include fpu_control.h on 32-bit x86 Message-ID: <201704112349.v3BNnFOl029262@aojmv0008.oracle.com> Changeset: d24c4dcd1acb Author: mikael Date: 2017-04-11 16:45 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/d24c4dcd1acb Only include fpu_control.h on 32-bit x86 ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp From mikael.vidstedt at oracle.com Wed Apr 12 00:00:01 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 17:00:01 -0700 Subject: RFR: Handle confstr version lookup failures gracefully Message-ID: During bootstrapping, os::Linux::libpthread_init() tries to discover the versions of (g)libc and libpthread respectively. This is done using confstr(3). However, musl doesn?t implement support for version discovery, so confstr will return 0/EINVAL. This change makes the code handle confstr failures gracefully, and defaults using the string ?unknown? if the version information cannot be looked up. http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 00:01:57 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 00:01:57 +0000 Subject: hg: portola/portola/hotspot: Handle confstr version lookup failures gracefully Message-ID: <201704120001.v3C01vaY002914@aojmv0008.oracle.com> Changeset: 2a55f49c4afc Author: mikael Date: 2017-04-11 16:59 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/2a55f49c4afc Handle confstr version lookup failures gracefully ! src/os/linux/vm/os_linux.cpp From mikael.vidstedt at oracle.com Wed Apr 12 00:07:46 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 17:07:46 -0700 Subject: RFR: Use SIGRTMAX instead of __SIGRTMAX Message-ID: <5391B9F3-73B4-4908-B5EF-46225EB7B305@oracle.com> The JDK uses (in two places) __SIGRTMAX, but posix refers to SIGRTMAX without the double-underscores prefix. Also, posix also mentions that SIGRTMAX is not guaranteed to be a constant expression. musl doesn?t define __SIGRTMAX, and the definition of SIGRTMAX is not a constant expression. This change updates the code to use SIGRTMAX, and also moves the initialization of the static global variable sigWakeup in linux_close.c to be initialized in the function just before the signal handler gets set up. http://cr.openjdk.java.net/~mikael/webrevs/portola/sigrtmax/webrev.00/jdk/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 00:09:20 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 00:09:20 +0000 Subject: hg: portola/portola/jdk: Use SIGRTMAX instead of __SIGRTMAX Message-ID: <201704120009.v3C09K2D004796@aojmv0008.oracle.com> Changeset: 519906d5d2f3 Author: mikael Date: 2017-04-11 17:07 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/519906d5d2f3 Use SIGRTMAX instead of __SIGRTMAX ! src/java.base/linux/native/libnet/linux_close.c ! src/java.base/unix/native/libnio/ch/NativeThread.c From david.holmes at oracle.com Wed Apr 12 00:08:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 10:08:33 +1000 Subject: RFR: Remove sys/ prefix from poll.h/signal.h includes In-Reply-To: <3724BBC4-5016-495A-A4CA-3FD8E6F2A375@oracle.com> References: <3724BBC4-5016-495A-A4CA-3FD8E6F2A375@oracle.com> Message-ID: <397571fd-ff99-08dd-ba01-e63f2f1aacaf@oracle.com> Hi Mikael, Changes look okay. I agree with the rationale. Looking at actual implementations, linux and mac OS are trivially fine (poll.h just includes sys/poll.h). Solaris is non-trivially fine - poll.h does more than what sys/poll.h does, but nothing that affects our sources. Thanks, David On 12/04/2017 8:42 AM, Mikael Vidstedt wrote: > > In several places in the JDK sources poll.h and signal.h are included through sys/{poll.h,signal.h}. The posix spec says the files should be included without the sys/ prefix, and musl issues a warning when sys/{poll.h,signal.h} are included. > > This change simple removes the sys/ prefix in all the relevant places. I?ve tried my best to verify that this works on all the platforms/toolchains I have access to, and also got help from the SAP guys to verify that it should work on AIX as well. > > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/pollsignal/webrev.00/hotspot/webrev/ > jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/pollsignal/webrev.00/jdk/webrev/ > > Cheers, > Mikael > From david.holmes at oracle.com Wed Apr 12 00:30:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 10:30:56 +1000 Subject: RFR: Use isnan instead of isnanf In-Reply-To: <88A94D3B-AE97-42BB-8F90-34EF1E6B316F@oracle.com> References: <88A94D3B-AE97-42BB-8F90-34EF1E6B316F@oracle.com> Message-ID: <60d5e494-e934-9db6-76fa-183ace63eb62@oracle.com> Hi Mikael, On 12/04/2017 9:04 AM, Mikael Vidstedt wrote: > > isnanf is not available in musl. posix says that isnan handles both float and double arguments (typically through a macro checking the size of the operand and delegation to the corresponding/actual isnan primitive). > > This change makes the two JDK wrapper macros call isnan instead of isnanf. I?ve tried to verify that the toolchains I have access to does the Right(tm) thing for float, but additional verification/testing is probably warranted before this is ?productized?. > > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/hotspot/webrev/ > jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/jdk/webrev/ Are we building with C99 support enabled? The feature test macros are shown as: isnan(): _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE || _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L; or cc -std=c99 isnanf(), isnanl(): _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 On linux we don't seem to do anything to explicitly enable access to either of these ?? Thanks, David > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 00:34:31 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 17:34:31 -0700 Subject: RFR: Make printing of rlim_t values more portable Message-ID: <9CAEDE1E-5035-4EDA-9F13-9BC5A35AA45F@oracle.com> os::Posix::print_rlimit_info has some logic to print a bunch of limit (rlim_t) values. posix doesn?t specify which exact type rlim_t has (just that it?s an unsigned integer type). Most platforms define it as an unsigned long, but in musl it?s an unsigned long long, which means that the print format (%lu) doesn?t match. There are a few different alternatives to fixing this, but Mikael Gerdin suggested upcasting the value to a 64-bit unsigned type and using the corresponding print format (UINT64_FORMAT). This should take care of the problem. http://cr.openjdk.java.net/~mikael/webrevs/portola/rlimit/webrev.01/hotspot/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 00:36:58 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 00:36:58 +0000 Subject: hg: portola/portola/hotspot: Make printing of rlim_t values more portable Message-ID: <201704120036.v3C0awMA011947@aojmv0008.oracle.com> Changeset: 5e381249f96d Author: mikael Date: 2017-04-11 17:35 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/5e381249f96d Make printing of rlim_t values more portable ! src/os/posix/vm/os_posix.cpp From mikael.vidstedt at oracle.com Wed Apr 12 01:07:16 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 18:07:16 -0700 Subject: RFR: Improve macros for libjdwp memory function overrides Message-ID: <76F97829-6A4A-4864-80F7-AFA9DAD5052E@oracle.com> The memory management functions (malloc, free, ?) should not be used directly in the libjdwp library. To catch any incorrect uses of the functions, the is a handful of macros in libjdwp/util.h which override the raw functions with something which will produce a build time error. Because of some the internal details of how the musl header files work, some system header files get included *after* the macro overrides, and the result is a bunch of (rather confusing) build time errors. I believe what happens is something along the lines of the following: libjdwp/util.h does this: #define calloc(p) Do not use this interface. Later, through some include chain, one of the system header files (sched.h) gets included. It contains some references to calloc, along the lines of: ... void *calloc(size_t, size_t); ? #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1, CPU_ALLOC_SIZE(n))) ... But since calloc has been redefined to a bunch of individual words/symbols, the result is an error pointing back to the original macro override definition in libjdwp/util.h: jdk/src/jdk.jdwp.agent/share/native/libjdwp/util.h:42:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'not' #define calloc(p,s) Do not use this interface. In either case, this change updates the macros to use a macro value which will still induce a build time error if the system memory functions are used in libjdwp (something like ?implicit declaration of function ?do_not_use_this_interface_malloc?), but which doesn?t produce a build time error in the normal/happy case. That said, this change is incomplete/fishy in the sense that there may well be cases where it?s the wrong thing to do. Specifically, the system header files may well expect to be able to do CPU_ALLOC/calloc implicitly, as part of some system function call or something else. I?ve tried to think of alternative solutions, but haven?t come up with anything so far. Taking suggestions, but meanwhile I?ll push this change. http://cr.openjdk.java.net/~mikael/webrevs/portola/memmacros/webrev.00/jdk/webrev/ Cheers, Mikael From david.holmes at oracle.com Wed Apr 12 01:08:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:08:05 +1000 Subject: RFR: Add limited support for -musl to config.sub In-Reply-To: References: Message-ID: <6ba6a2fa-00ee-c3d4-4ef1-a9487f04f2f1@oracle.com> On 12/04/2017 9:14 AM, Mikael Vidstedt wrote: > > The version of autoconfig-config.sub checked into the JDK repo is old enough to not support/handle musl. This change adds (very) limited support for handling musl tuples. Specifically, it *only* handles the exact tuple 'x86_64-unknown-linux-musl' and handles it by returning the exact same tuple string. > > This clearly needs to be made more flexible going forward, and I?m following up on options to do so. Meanwhile, this at least works well enough to get something building. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/configsub/webrev.00/webrev/ Ok. David > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 01:09:29 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 01:09:29 +0000 Subject: hg: portola/portola/jdk: Improve macros for libjdwp memory function overrides Message-ID: <201704120109.v3C19TDE021060@aojmv0008.oracle.com> Changeset: 887e233f7fb5 Author: mikael Date: 2017-04-11 18:07 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/887e233f7fb5 Improve macros for libjdwp memory function overrides ! src/jdk.jdwp.agent/share/native/libjdwp/util.h From david.holmes at oracle.com Wed Apr 12 01:11:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:11:15 +1000 Subject: RFR: Remove execinfo debug code from XToolkit.c In-Reply-To: <4C391CDA-715A-48DE-87A9-41DEDE6ECB93@oracle.com> References: <4C391CDA-715A-48DE-87A9-41DEDE6ECB93@oracle.com> Message-ID: <3a8ee7d9-4c2c-9f3f-02b1-fc0be91048bc@oracle.com> On 12/04/2017 9:23 AM, Mikael Vidstedt wrote: > > XToolkit.c has some linux specific debug code in it which is effectively dead. The debug code depends on backtracing functionality from execinfo.h, but musl does not implement/support execinfo.h. > > Since the code is dead, I chose to remove it. In case it turns out that this debugging code gets used a lot when chasing down bugs etc. we?ll have to look at how to support it on musl, or perhaps only enable it if execinfo.h is available. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/execinfo/webrev.00/jdk/webrev/ Ok. Certainly looks dead. Thanks, David > Cheers, > Mikael > From david.holmes at oracle.com Wed Apr 12 01:18:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:18:50 +1000 Subject: RFR: Only include fpu_control.h on 32-bit x86 In-Reply-To: <9F64D3DF-76B0-41EB-94EF-A4255CBEA750@oracle.com> References: <9F64D3DF-76B0-41EB-94EF-A4255CBEA750@oracle.com> Message-ID: <2fd0d9f6-06bf-e945-ac61-1c396488c67f@oracle.com> On 12/04/2017 9:46 AM, Mikael Vidstedt wrote: > > os_linux_x86_.cpp has some code to set/update/tickle the fpu control word. The code makes use of functions from the fpu_control.h header, but is only used on 32-bit x86. musl doesn?t have the fpu_control.h header file. So musl doesn't support 32-bit x86? > This change adds a conditional include guard to only include the fpu_control.h on 32-bit x86 (!AMD64), which matches the guards used in the places further down in the file where the functionality is actually used. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/fpucontrol/webrev.00/hotspot/webrev/ Using a consistent guard makes a lot of sense. I wonder if we even need this FPU control word stuff these days ... Thanks, David > Cheers, > Mikael > From david.holmes at oracle.com Wed Apr 12 01:27:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:27:09 +1000 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: References: Message-ID: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: > > During bootstrapping, os::Linux::libpthread_init() tries to discover the versions of (g)libc and libpthread respectively. This is done using confstr(3). However, musl doesn?t implement support for version discovery, so confstr will return 0/EINVAL. > > This change makes the code handle confstr failures gracefully, and defaults using the string ?unknown? if the version information cannot be looked up. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ There was no need to separate out the declaration here: 504 size_t n; 505 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); Overall I don't think this change is quite what we would want in that it is wrong to print "unknown" when in fact there is no libc (or libpthread?) involved. And we would surely want to see that we are using musl. Thanks, David > Cheers, > Mikael > From david.holmes at oracle.com Wed Apr 12 01:34:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:34:20 +1000 Subject: RFR: Use SIGRTMAX instead of __SIGRTMAX In-Reply-To: <5391B9F3-73B4-4908-B5EF-46225EB7B305@oracle.com> References: <5391B9F3-73B4-4908-B5EF-46225EB7B305@oracle.com> Message-ID: On 12/04/2017 10:07 AM, Mikael Vidstedt wrote: > > The JDK uses (in two places) __SIGRTMAX, but posix refers to SIGRTMAX without the double-underscores prefix. Also, posix also mentions that SIGRTMAX is not guaranteed to be a constant expression. musl doesn?t define __SIGRTMAX, and the definition of SIGRTMAX is not a constant expression. > > This change updates the code to use SIGRTMAX, Ok. Hotspot uses SIGRTMAX so there should be no issues here. > and also moves the initialization of the static global variable sigWakeup in linux_close.c to be initialized in the function just before the signal handler gets set up. Why do we need to move the initialization?? Thanks, David > http://cr.openjdk.java.net/~mikael/webrevs/portola/sigrtmax/webrev.00/jdk/webrev/ > > Cheers, > Mikael > From david.holmes at oracle.com Wed Apr 12 01:37:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:37:47 +1000 Subject: RFR: Make printing of rlim_t values more portable In-Reply-To: <9CAEDE1E-5035-4EDA-9F13-9BC5A35AA45F@oracle.com> References: <9CAEDE1E-5035-4EDA-9F13-9BC5A35AA45F@oracle.com> Message-ID: On 12/04/2017 10:34 AM, Mikael Vidstedt wrote: > > os::Posix::print_rlimit_info has some logic to print a bunch of limit (rlim_t) values. posix doesn?t specify which exact type rlim_t has (just that it?s an unsigned integer type). Most platforms define it as an unsigned long, but in musl it?s an unsigned long long, which means that the print format (%lu) doesn?t match. > > There are a few different alternatives to fixing this, but Mikael Gerdin suggested upcasting the value to a 64-bit unsigned type and using the corresponding print format (UINT64_FORMAT). This should take care of the problem. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/rlimit/webrev.01/hotspot/webrev/ A reasonable approach, but stylistically I'd prefer to use uint64_t in the cast rather than the u8 shorthand. Or perhaps we need U_FORMAT definitions to match. Thanks, David > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 01:42:00 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 18:42:00 -0700 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> Message-ID: <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> > On Apr 11, 2017, at 6:27 PM, David Holmes wrote: > > On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >> >> During bootstrapping, os::Linux::libpthread_init() tries to discover the versions of (g)libc and libpthread respectively. This is done using confstr(3). However, musl doesn?t implement support for version discovery, so confstr will return 0/EINVAL. >> >> This change makes the code handle confstr failures gracefully, and defaults using the string ?unknown? if the version information cannot be looked up. >> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ > > There was no need to separate out the declaration here: > > 504 size_t n; > 505 > 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); > > Overall I don't think this change is quite what we would want in that it is wrong to print "unknown" when in fact there is no libc (or libpthread?) involved. And we would surely want to see that we are using musl. Since the variable is reused for the second confstr call I prefer to declare it separately. In an upcoming change I have added support for adding ?-musl? to the (internal) version string so that we can at least see that it?s a musl VM instead of a glibc one. There is a libc - musl. libpthread happens to be part of that same libc instead of being a separate library, so depending on how you look at it there is or isn?t a libpthread (it is effectively an implementation detail of musl). The problem is that there?s no way of getting the version information at runtime with musl... Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 01:43:55 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 18:43:55 -0700 Subject: RFR: Use SIGRTMAX instead of __SIGRTMAX In-Reply-To: References: <5391B9F3-73B4-4908-B5EF-46225EB7B305@oracle.com> Message-ID: > On Apr 11, 2017, at 6:34 PM, David Holmes wrote: > > On 12/04/2017 10:07 AM, Mikael Vidstedt wrote: >> >> The JDK uses (in two places) __SIGRTMAX, but posix refers to SIGRTMAX without the double-underscores prefix. Also, posix also mentions that SIGRTMAX is not guaranteed to be a constant expression. musl doesn?t define __SIGRTMAX, and the definition of SIGRTMAX is not a constant expression. >> >> This change updates the code to use SIGRTMAX, > > Ok. Hotspot uses SIGRTMAX so there should be no issues here. > >> and also moves the initialization of the static global variable sigWakeup in linux_close.c to be initialized in the function just before the signal handler gets set up. > > Why do we need to move the initialization?? The musl definition of SIGRTMAX is not a constant expression - it?s a function call. Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 01:44:40 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 18:44:40 -0700 Subject: RFR: Make printing of rlim_t values more portable In-Reply-To: References: <9CAEDE1E-5035-4EDA-9F13-9BC5A35AA45F@oracle.com> Message-ID: > On Apr 11, 2017, at 6:37 PM, David Holmes wrote: > > On 12/04/2017 10:34 AM, Mikael Vidstedt wrote: >> >> os::Posix::print_rlimit_info has some logic to print a bunch of limit (rlim_t) values. posix doesn?t specify which exact type rlim_t has (just that it?s an unsigned integer type). Most platforms define it as an unsigned long, but in musl it?s an unsigned long long, which means that the print format (%lu) doesn?t match. >> >> There are a few different alternatives to fixing this, but Mikael Gerdin suggested upcasting the value to a 64-bit unsigned type and using the corresponding print format (UINT64_FORMAT). This should take care of the problem. >> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/rlimit/webrev.01/hotspot/webrev/ > > A reasonable approach, but stylistically I'd prefer to use uint64_t in the cast rather than the u8 shorthand. Or perhaps we need U_FORMAT definitions to match. I agree that uint64_t would be better. Will fix! Cheers, Mikael From david.holmes at oracle.com Wed Apr 12 01:46:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:46:51 +1000 Subject: RFR: Improve macros for libjdwp memory function overrides In-Reply-To: <76F97829-6A4A-4864-80F7-AFA9DAD5052E@oracle.com> References: <76F97829-6A4A-4864-80F7-AFA9DAD5052E@oracle.com> Message-ID: On 12/04/2017 11:07 AM, Mikael Vidstedt wrote: > > The memory management functions (malloc, free, ?) should not be used directly in the libjdwp library. To catch any incorrect uses of the functions, the is a handful of macros in libjdwp/util.h which override the raw functions with something which will produce a build time error. > > Because of some the internal details of how the musl header files work, some system header files get included *after* the macro overrides, and the result is a bunch of (rather confusing) build time errors. I believe what happens is something along the lines of the following: > > libjdwp/util.h does this: > > #define calloc(p) Do not use this interface. > > Later, through some include chain, one of the system header files (sched.h) gets included. It contains some references to calloc, along the lines of: > > ... > void *calloc(size_t, size_t); > ? > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1, CPU_ALLOC_SIZE(n))) > ... > > But since calloc has been redefined to a bunch of individual words/symbols, the result is an error pointing back to the original macro override definition in libjdwp/util.h: > > jdk/src/jdk.jdwp.agent/share/native/libjdwp/util.h:42:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'not' > #define calloc(p,s) Do not use this interface. > > In either case, this change updates the macros to use a macro value which will still induce a build time error if the system memory functions are used in libjdwp (something like ?implicit declaration of function ?do_not_use_this_interface_malloc?), but which doesn?t produce a build time error in the normal/happy case. > > That said, this change is incomplete/fishy in the sense that there may well be cases where it?s the wrong thing to do. Specifically, the system header files may well expect to be able to do CPU_ALLOC/calloc implicitly, as part of some system function call or something else. I?ve tried to think of alternative solutions, but haven?t come up with anything so far. Taking suggestions, but meanwhile I?ll push this change. I would suggest ensuring that util.h is always the last include in the .c files - that will avoid any possible interference with system headers. If that is not possible then I suggest moving this set of defines to a new header file which can be included last. The current approach is potentially broken, as you note, if any of the affected system headers actually use the redefined functions in their own macro expansions. Thanks, David > http://cr.openjdk.java.net/~mikael/webrevs/portola/memmacros/webrev.00/jdk/webrev/ > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 01:48:10 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 01:48:10 +0000 Subject: hg: portola/portola/hotspot: Use uint64_t instead of u8 for rlim_t Message-ID: <201704120148.v3C1mBol001392@aojmv0008.oracle.com> Changeset: be0511671863 Author: mikael Date: 2017-04-11 18:46 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/be0511671863 Use uint64_t instead of u8 for rlim_t ! src/os/posix/vm/os_posix.cpp From david.holmes at oracle.com Wed Apr 12 01:58:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 11:58:30 +1000 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> Message-ID: <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> On 12/04/2017 11:42 AM, Mikael Vidstedt wrote: > >> On Apr 11, 2017, at 6:27 PM, David Holmes wrote: >> >> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >>> >>> During bootstrapping, os::Linux::libpthread_init() tries to discover the versions of (g)libc and libpthread respectively. This is done using confstr(3). However, musl doesn?t implement support for version discovery, so confstr will return 0/EINVAL. >>> >>> This change makes the code handle confstr failures gracefully, and defaults using the string ?unknown? if the version information cannot be looked up. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ >> >> There was no need to separate out the declaration here: >> >> 504 size_t n; >> 505 >> 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); >> >> Overall I don't think this change is quite what we would want in that it is wrong to print "unknown" when in fact there is no libc (or libpthread?) involved. And we would surely want to see that we are using musl. > > Since the variable is reused for the second confstr call I prefer to declare it separately. Declaring uninitialized variables is an anachronism IMHO. :) > In an upcoming change I have added support for adding ?-musl? to the (internal) version string so that we can at least see that it?s a musl VM instead of a glibc one. > > There is a libc - musl. libpthread happens to be part of that same libc instead of being a separate library, so depending on how you look at it there is or isn?t a libpthread (it is effectively an implementation detail of musl). The problem is that there?s no way of getting the version information at runtime with musl... So if we can detect that we are musl then the libc version should be "musl" and the libpthread version should be "" (or something like that. I'm surprised there is no mechanism at all for runtime detection of musl! But musl defines in unistd.h #define _CS_GNU_LIBC_VERSION 2 #define _CS_GNU_LIBPTHREAD_VERSION 3 so won't those be reported by confstr ?? Thanks, David > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 01:58:58 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 18:58:58 -0700 Subject: RFR: Only use dlvsym for libnuma lookups if it's available Message-ID: In os_linux.cpp/os::Linux::libnuma_dlsym dlvsym(3) is used to do versioned lookup of various libnuma symbols. According to the JBS issue [1] corresponding to the change which introduced it, the reason seems to be that the NUMA API changed between versions, and that dlsym in some cases found the newest version of the libnuma symbols where the VM expects to get the older version. This all seems messy at best.. dlvsym is not available in musl. Just to work around the problem, I use dlsym to look up dlvsym, and only use it if it is available. While it does solve the immediate problem, I have to wonder if there isn?t a better way to do this. http://cr.openjdk.java.net/~mikael/webrevs/portola/dlvsym/webrev.00/hotspot/webrev/ Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-6840196 From mikael.vidstedt at oracle.com Wed Apr 12 02:06:48 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 19:06:48 -0700 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> Message-ID: > On Apr 11, 2017, at 6:58 PM, David Holmes wrote: > > On 12/04/2017 11:42 AM, Mikael Vidstedt wrote: >> >>> On Apr 11, 2017, at 6:27 PM, David Holmes wrote: >>> >>> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >>>> >>>> During bootstrapping, os::Linux::libpthread_init() tries to discover the versions of (g)libc and libpthread respectively. This is done using confstr(3). However, musl doesn?t implement support for version discovery, so confstr will return 0/EINVAL. >>>> >>>> This change makes the code handle confstr failures gracefully, and defaults using the string ?unknown? if the version information cannot be looked up. >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ >>> >>> There was no need to separate out the declaration here: >>> >>> 504 size_t n; >>> 505 >>> 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); >>> >>> Overall I don't think this change is quite what we would want in that it is wrong to print "unknown" when in fact there is no libc (or libpthread?) involved. And we would surely want to see that we are using musl. >> >> Since the variable is reused for the second confstr call I prefer to declare it separately. > > Declaring uninitialized variables is an anachronism IMHO. :) > >> In an upcoming change I have added support for adding ?-musl? to the (internal) version string so that we can at least see that it?s a musl VM instead of a glibc one. >> >> There is a libc - musl. libpthread happens to be part of that same libc instead of being a separate library, so depending on how you look at it there is or isn?t a libpthread (it is effectively an implementation detail of musl). The problem is that there?s no way of getting the version information at runtime with musl... > > So if we can detect that we are musl then the libc version should be "musl" and the libpthread version should be "" (or something like that. That?s fair. My upcoming change will pass in the target C library as an explicit compiler define. Detecting it at runtime is AFAICT not possible. Once I have the change in place I can go back and update the values of these two ?versions?. > I'm surprised there is no mechanism at all for runtime detection of musl! > > But musl defines in unistd.h > > #define _CS_GNU_LIBC_VERSION 2 > #define _CS_GNU_LIBPTHREAD_VERSION 3 > > so won't those be reported by confstr ?? Unfortunately not. confstr will return 0/EINVAL for almost all arguments. Those two defines are likely only there to make code compile at all with musl, but if confstr is actually called at runtime with any of those values it will return an error. Cheers, Mikael > > Thanks, > David > >> Cheers, >> Mikael From mikael.vidstedt at oracle.com Wed Apr 12 02:08:41 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 02:08:41 +0000 Subject: hg: portola/portola/hotspot: Only use dlvsym for libnuma lookups if it's available Message-ID: <201704120208.v3C28fOB006608@aojmv0008.oracle.com> Changeset: dd3e7aeb56ed Author: mikael Date: 2017-04-11 19:06 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/dd3e7aeb56ed Only use dlvsym for libnuma lookups if it's available ! src/os/linux/vm/os_linux.cpp From david.holmes at oracle.com Wed Apr 12 02:31:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 12:31:56 +1000 Subject: RFR: Only use dlvsym for libnuma lookups if it's available In-Reply-To: References: Message-ID: On 12/04/2017 11:58 AM, Mikael Vidstedt wrote: > > In os_linux.cpp/os::Linux::libnuma_dlsym dlvsym(3) is used to do versioned lookup of various libnuma symbols. According to the JBS issue [1] corresponding to the change which introduced it, the reason seems to be that the NUMA API changed between versions, and that dlsym in some cases found the newest version of the libnuma symbols where the VM expects to get the older version. This all seems messy at best.. > > dlvsym is not available in musl. Just to work around the problem, I use dlsym to look up dlvsym, and only use it if it is available. While it does solve the immediate problem, I have to wonder if there isn?t a better way to do this. That seems a reasonable workaround - and consistent with how we deal with functions that may be version specific. A bit of googling indicates that symbol versioning in DSOs is pretty much a complete disaster :( But I wonder if this problem still exists on the versions of linux we support? Thanks, David > http://cr.openjdk.java.net/~mikael/webrevs/portola/dlvsym/webrev.00/hotspot/webrev/ > > Cheers, > Mikael > > [1] https://bugs.openjdk.java.net/browse/JDK-6840196 > From mikael.vidstedt at oracle.com Wed Apr 12 02:35:49 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 19:35:49 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher Message-ID: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> This one is a big tricky: http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ The end goal is to get the launcher (java_md_solinux.c) to add the path to libjvm.so to LD_LIBRARY_PATH, but to only do so if running/building for musl. Here?s the comment I added to java_md_solinux.c, which hopefully explains why this is needed: /* * The musl library loader requires LD_LIBRARY_PATH to be set in * order to correctly resolve the dependency libjava.so has on libjvm.so. * * Specifically, it differs from glibc in the sense that even if * libjvm.so has already been loaded it will not be considered a * candidate for resolving the dependency unless the *full* path * of the already loaded library matches the dependency being loaded. * * libjvm.so is being loaded by the launcher using a long path to * dlopen, not just the basename of the library. Typically this * is something like "../lib/server/libjvm.so". However, if/when * libjvm.so later tries to dlopen libjava.so (which it does in * order to get access to a few functions implemented in * libjava.so) the musl loader will, as part of loading * dependent libraries, try to load libjvm.so using only its * basename "libjvm.so". Since this does not match the longer * path path it was first loaded with, the already loaded * library is not considered a candidate, and the loader will * instead look for libjvm.so elsewhere. If it's not in * LD_LIBRARY_PATH the dependency load will fail, and libjava.so * will therefore fail as well. */ Since there is no way to know at runtime that musl is being used, and there is no ?system? compile time define to base the decision on, this change adds support to the JDK build system to set up a OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, passing in the value to java_md_solinux.c as a compiler define -DCLIB=???, using that define to check for musl in RequiresSetenv, and returning true to force the setting of LD_LIBRARY_PATH if there?s a match. Definitely could use some feedback on this one. Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 02:39:12 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 19:39:12 -0700 Subject: RFR: Only use dlvsym for libnuma lookups if it's available In-Reply-To: References: Message-ID: <6A270E88-8A36-4901-83E2-BD6CB2B07C57@oracle.com> > On Apr 11, 2017, at 7:31 PM, David Holmes wrote: > > On 12/04/2017 11:58 AM, Mikael Vidstedt wrote: >> >> In os_linux.cpp/os::Linux::libnuma_dlsym dlvsym(3) is used to do versioned lookup of various libnuma symbols. According to the JBS issue [1] corresponding to the change which introduced it, the reason seems to be that the NUMA API changed between versions, and that dlsym in some cases found the newest version of the libnuma symbols where the VM expects to get the older version. This all seems messy at best.. >> >> dlvsym is not available in musl. Just to work around the problem, I use dlsym to look up dlvsym, and only use it if it is available. While it does solve the immediate problem, I have to wonder if there isn?t a better way to do this. > > That seems a reasonable workaround - and consistent with how we deal with functions that may be version specific. > > A bit of googling indicates that symbol versioning in DSOs is pretty much a complete disaster :( But I wonder if this problem still exists on the versions of linux we support? That question did occur to me as well. Definitely worth following up on at some point. Cheers, Mikael From david.holmes at oracle.com Wed Apr 12 02:43:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 12:43:57 +1000 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> Message-ID: <937ccb3f-4af5-0564-d8a9-57515578f192@oracle.com> On 12/04/2017 12:06 PM, Mikael Vidstedt wrote: > >> On Apr 11, 2017, at 6:58 PM, David Holmes > > wrote: >> >> On 12/04/2017 11:42 AM, Mikael Vidstedt wrote: >>> >>>> On Apr 11, 2017, at 6:27 PM, David Holmes >>> > wrote: >>>> >>>> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >>>>> >>>>> During bootstrapping, os::Linux::libpthread_init() tries to >>>>> discover the versions of (g)libc and libpthread respectively. This >>>>> is done using confstr(3). However, musl doesn?t implement support >>>>> for version discovery, so confstr will return 0/EINVAL. >>>>> >>>>> This change makes the code handle confstr failures gracefully, and >>>>> defaults using the string ?unknown? if the version information >>>>> cannot be looked up. >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ >>>> >>>> There was no need to separate out the declaration here: >>>> >>>> 504 size_t n; >>>> 505 >>>> 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); >>>> >>>> Overall I don't think this change is quite what we would want in >>>> that it is wrong to print "unknown" when in fact there is no libc >>>> (or libpthread?) involved. And we would surely want to see that we >>>> are using musl. >>> >>> Since the variable is reused for the second confstr call I prefer to >>> declare it separately. >> >> Declaring uninitialized variables is an anachronism IMHO. :) >> >>> In an upcoming change I have added support for adding ?-musl? to the >>> (internal) version string so that we can at least see that it?s a >>> musl VM instead of a glibc one. >>> >>> There is a libc - musl. libpthread happens to be part of that same >>> libc instead of being a separate library, so depending on how you >>> look at it there is or isn?t a libpthread (it is effectively an >>> implementation detail of musl). The problem is that there?s no way of >>> getting the version information at runtime with musl... >> >> So if we can detect that we are musl then the libc version should be >> "musl" and the libpthread version should be "" (or >> something like that. > > That?s fair. My upcoming change will pass in the target C library as an > explicit compiler define. Detecting it at runtime is AFAICT not > possible. Once I have the change in place I can go back and update the > values of these two ?versions?. > >> I'm surprised there is no mechanism at all for runtime detection of musl! >> >> But musl defines in unistd.h >> >> #define _CS_GNU_LIBC_VERSION2 >> #define _CS_GNU_LIBPTHREAD_VERSION3 >> >> so won't those be reported by confstr ?? > > Unfortunately not. confstr will return 0/EINVAL for almost all > arguments. Those two defines are likely only there to make code compile > at all with musl, but if confstr is actually called at runtime with any > of those values it will return an error. I can not make any sense out of: https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c Quality code - love the clear explanatory comments. :( David > > Cheers, > Mikael > >> >> Thanks, >> David >> >>> Cheers, >>> Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 02:44:07 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 19:44:07 -0700 Subject: RFR: Only include fpu_control.h on 32-bit x86 In-Reply-To: <2fd0d9f6-06bf-e945-ac61-1c396488c67f@oracle.com> References: <9F64D3DF-76B0-41EB-94EF-A4255CBEA750@oracle.com> <2fd0d9f6-06bf-e945-ac61-1c396488c67f@oracle.com> Message-ID: > On Apr 11, 2017, at 6:18 PM, David Holmes wrote: > > On 12/04/2017 9:46 AM, Mikael Vidstedt wrote: >> >> os_linux_x86_.cpp has some code to set/update/tickle the fpu control word. The code makes use of functions from the fpu_control.h header, but is only used on 32-bit x86. musl doesn?t have the fpu_control.h header file. > > So musl doesn't support 32-bit x86? I believe there is support in musl for 32-bit x86, and perhaps there is something else we can use to update the fpu control word. For now though, I suggest that we focus on linux/x64. If/when we have everything working on linux/x64 we can go back and add support for other platforms/CPU architectures. > >> This change adds a conditional include guard to only include the fpu_control.h on 32-bit x86 (!AMD64), which matches the guards used in the places further down in the file where the functionality is actually used. >> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/fpucontrol/webrev.00/hotspot/webrev/ > > Using a consistent guard makes a lot of sense. > > I wonder if we even need this FPU control word stuff these days ? Unclear. Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 02:49:26 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 19:49:26 -0700 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: <937ccb3f-4af5-0564-d8a9-57515578f192@oracle.com> References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> <937ccb3f-4af5-0564-d8a9-57515578f192@oracle.com> Message-ID: > On Apr 11, 2017, at 7:43 PM, David Holmes wrote: > > > > On 12/04/2017 12:06 PM, Mikael Vidstedt wrote: >> >>> On Apr 11, 2017, at 6:58 PM, David Holmes >>> >> wrote: >>> >>> On 12/04/2017 11:42 AM, Mikael Vidstedt wrote: >>>> >>>>> On Apr 11, 2017, at 6:27 PM, David Holmes >>>>> >> wrote: >>>>> >>>>> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >>>>>> >>>>>> During bootstrapping, os::Linux::libpthread_init() tries to >>>>>> discover the versions of (g)libc and libpthread respectively. This >>>>>> is done using confstr(3). However, musl doesn?t implement support >>>>>> for version discovery, so confstr will return 0/EINVAL. >>>>>> >>>>>> This change makes the code handle confstr failures gracefully, and >>>>>> defaults using the string ?unknown? if the version information >>>>>> cannot be looked up. >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ >>>>> >>>>> There was no need to separate out the declaration here: >>>>> >>>>> 504 size_t n; >>>>> 505 >>>>> 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); >>>>> >>>>> Overall I don't think this change is quite what we would want in >>>>> that it is wrong to print "unknown" when in fact there is no libc >>>>> (or libpthread?) involved. And we would surely want to see that we >>>>> are using musl. >>>> >>>> Since the variable is reused for the second confstr call I prefer to >>>> declare it separately. >>> >>> Declaring uninitialized variables is an anachronism IMHO. :) >>> >>>> In an upcoming change I have added support for adding ?-musl? to the >>>> (internal) version string so that we can at least see that it?s a >>>> musl VM instead of a glibc one. >>>> >>>> There is a libc - musl. libpthread happens to be part of that same >>>> libc instead of being a separate library, so depending on how you >>>> look at it there is or isn?t a libpthread (it is effectively an >>>> implementation detail of musl). The problem is that there?s no way of >>>> getting the version information at runtime with musl... >>> >>> So if we can detect that we are musl then the libc version should be >>> "musl" and the libpthread version should be "" (or >>> something like that. >> >> That?s fair. My upcoming change will pass in the target C library as an >> explicit compiler define. Detecting it at runtime is AFAICT not >> possible. Once I have the change in place I can go back and update the >> values of these two ?versions?. >> >>> I'm surprised there is no mechanism at all for runtime detection of musl! >>> >>> But musl defines in unistd.h >>> >>> #define _CS_GNU_LIBC_VERSION2 >>> #define _CS_GNU_LIBPTHREAD_VERSION3 >>> >>> so won't those be reported by confstr ?? >> >> Unfortunately not. confstr will return 0/EINVAL for almost all >> arguments. Those two defines are likely only there to make code compile >> at all with musl, but if confstr is actually called at runtime with any >> of those values it will return an error. > > I can not make any sense out of: > > https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c > > Quality code - love the clear explanatory comments. :( I?ve stared at that one before wondering what the second if statement is trying to express, but in either case it?s not going to return anything useful :) Cheers, Mikael > > David > >> >> Cheers, >> Mikael >> >>> >>> Thanks, >>> David >>> >>>> Cheers, >>>> Mikael From david.holmes at oracle.com Wed Apr 12 03:55:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 13:55:26 +1000 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> Message-ID: On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: > > This one is a big tricky: > > http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ > > The end goal is to get the launcher (java_md_solinux.c) to add the path to libjvm.so to LD_LIBRARY_PATH, but to only do so if running/building for musl. Here?s the comment I added to java_md_solinux.c, which hopefully explains why this is needed: > > /* > * The musl library loader requires LD_LIBRARY_PATH to be set in > * order to correctly resolve the dependency libjava.so has on libjvm.so. I had not realized that the dynamic loader was part of libc. I had assumed it was part of the OS proper. > * > * Specifically, it differs from glibc in the sense that even if > * libjvm.so has already been loaded it will not be considered a > * candidate for resolving the dependency unless the *full* path > * of the already loaded library matches the dependency being loaded. > * > * libjvm.so is being loaded by the launcher using a long path to > * dlopen, not just the basename of the library. Typically this > * is something like "../lib/server/libjvm.so". However, if/when > * libjvm.so later tries to dlopen libjava.so (which it does in > * order to get access to a few functions implemented in > * libjava.so) the musl loader will, as part of loading > * dependent libraries, try to load libjvm.so using only its > * basename "libjvm.so". Since this does not match the longer > * path path it was first loaded with, the already loaded > * library is not considered a candidate, and the loader will > * instead look for libjvm.so elsewhere. If it's not in > * LD_LIBRARY_PATH the dependency load will fail, and libjava.so > * will therefore fail as well. > */ > Since there is no way to know at runtime that musl is being used, and there is no ?system? compile time define to base the decision on, this change adds support to the JDK build system to set up a OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, passing in the value to java_md_solinux.c as a compiler define -DCLIB=???, using that define to check for musl in RequiresSetenv, and returning true to force the setting of LD_LIBRARY_PATH if there?s a match. But we can infer we are using musl if we don't get any glibc version information. David ----- > Definitely could use some feedback on this one. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 04:55:44 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 21:55:44 -0700 Subject: RFR: Unaligned pointer dereference crash in ClassFileParser Message-ID: <2675F2D9-95FD-438B-8B58-A06B5CCD75DB@oracle.com> This one is interesting, and requires a bit of background. Get yourself a cup of coffee/tea if you haven?t already. I?d actually like to push this this jdk10 as well sometime soon-ish, because it?s an actual/latent bug which may be tickled if our toolchain changes in some way. It?s not actually a musl bug per-se, it just happens to be tickled when compiling for musl. webrev: http://cr.openjdk.java.net/~mikael/webrevs/portola/copyswapaligned/webrev.00/hotspot/webrev/ The story goes something like this: x86 is normally very forgiving when it comes to dereferencing unaligned pointers. Even if the pointer isn?t aligned on the natural size of the element being accessed, the hardware will do the Right Thing(tm) and nobody gets hurt. However, turns out there are exceptions to this. Specifically, SSA2 introduced the movdqa instruction, which is a 128-bit load/store which *does* require that the pointer is 128-bit aligned. Normally this isn?t a problem, because after all we don?t typically use 128-bit data types in our C/C++ code. However, just because we don?t use any such data types explicitly, there?s nothing preventing the C compiler to do so under the covers. Specifically, the C compiler tends to do loop unrolling and vectorization, which can turn pretty much any data access into vectorized SIMD accesses. We?ve actually run into a variation on this exact same problem a while back when upgrading to gcc 4.9.2 [1]. That time the problem was in nio/Bits.c, and it was fixed (by me) by moving the copy functionality into hotspot (copy.[ch]pp), making sure the copy logic does the relevant alignment checks etc. This time the problem is with ClassFileParser. Or more accurately, it?s in the methods ClassFileParser makes use of. Specifically, the problem is with the copy_u2_with_conversion method, used to copy various data from the class file and put it in the ?native? endian order in memory. It, in turn, uses Bytes::get_Java_u2 to read and potentially byte swap a 16-bit entry from the class file. bytes_x86.hpp has this to say about its implementation: // Efficient reading and writing of unaligned unsigned data in platform-specific byte ordering // (no special code is needed since x86 CPUs can access unaligned data) While that is /almost/ always true for the x86 architecture in itself, the C standard still expects accesses to be aligned, and the C compiler is free to make use of that expectation to, for example, vectorize operations and make use of the movdqa instruction. So why is this only a problem when using musl? Turns out it sorta isn?t, but bytes_x86.hpp will, in the end, actually use system library functions to do byte swapping. Specifically, on linux_x86 it will come down to bytes_linux_x86.inline.hpp which, on AMD64, uses the system functions/macros swap_u{16,32,64} to do the actual byte swapping. Now here?s the ?funny? & interesting part: With glibc, the swap_u{16,32,64} methods are implemented using inline assembly - in the end it comes down to a rotate ?rorw? instruction. Since GCC can?t see through the inline assembly, it will not realize that there are loop unrolling/vectorization opportunities, and of specific interest to us: the movdqa instruction will not be used. The code will potentially not be as efficient as it could be, but it will be functional. With musl, the swap methods are instead implemented as normal macros, shifting bits around to achieve the desired effect. GCC recognizes the bit shifting patterns, will realize that it?s just byte swapping a bunch of values, will vectorize the loop, and *will* make use of the movdqa instruction. Kaboom. To recap: dereferencing unaligned pointers in C/C++ is a no-no, even in cases where you think it should be okay. That concludes the background. Let?s move over to the suggested fix. There are (at least) two alternatives: 1. Only fix the specific case of classFileStream.cpp/copy_u2_with_conversion 2. Address the larger problem of Bytes providing methods which may not be safe For better or worse, the webrev I linked to above does the latter - it doesn?t just do the minimal change. I?m happy to revisit that and reduce the scope of the patch if needed. The key changes are in three different areas, the first two of which are needed (in one way or another): * copy.[ch]pp Introducing: conjoint_swap_maybe conjoint_swap_maybe will copy data, and bytes wap it on-the-fly if the specified endianness differs from the native/CPU endianness. It does this by either delegating to conjoint_swap (on endian mismatch), or conjoint_copy (on match). In copy.cpp, the changes all boil down to making the innermost do_conjoint_swap method more flexible so that it can be reused for both cases (straight copy as well as copy+swap). * classFile{Parser,Stream} The key (and only absolutely needed) change is in classFileParser.cpp, switching to copying data from the class file using the new conjoint_swap_maybe method, replacing the loop implemented in copy_u2_with_conversion/Bytes::get_Java_u2. However, in addition to that change, I noticed that there are a lot of u2* passed around in the code, pointers which are not necessarily 16-bit aligned. While there?s nothing wrong with *having* an unaligned pointer in C - as long as it?s not dereferenced everything is peachy - it made me uneasy to see it passed around and used the way it is. Specifically, ClassFileStream::get_u2_buffer() could, to the untrained eye, be a bit misleading. One could accidentally and incorrectly assume that the returned pointer is, in fact, 16-bit aligned and start dereferencing it directly, where in fact there is no such guarantee. Perhaps even use it as an array and attract the wrath of the C compiler. Changing to void* may or may not be the right thing to do here. In a way I?d actually like to ?carry? the type information, but in some way still prevent the pointer from being directly dereferenced. Taking suggestions. * bytes_x86.hpp Note: I believe that given the above changes, this one isn?t absolutely necessary. This is addressing the wider concern that other parts of hotspot may use the same primitives in much the same (potentially broken) way, and in particular the fact that the get/put primitives aren?t checking whether the pointer argument is aligned before they dereference it. It may well be that a simple assert or two would do the trick here. That said: It turns out that the various platforms all have their own unique ways of implementing bytes.hpp, duplicating some logic which could/should be platform independent. I tried to clean up and unify it all a bit while at it by introducing an Endian helper class in bytes.hpp. The primitives for accessing data in memory now check for alignment and either perform the raw memory access (when the pointer is aligned), or does a memcpy (if unaligned). There?s some template ?magic? in there avoid duplicating code, but hopefully the magic is relatively straightforward. Appreciate any and all comments and feedback. As mentioned, I think this is worth pushing to jdk10 as well in some not-all-too-distant future. Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-8141491 From mikael.vidstedt at oracle.com Wed Apr 12 05:23:37 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 11 Apr 2017 22:23:37 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> Message-ID: <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> > On Apr 11, 2017, at 8:55 PM, David Holmes wrote: > > On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: >> >> This one is a big tricky: >> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ >> >> The end goal is to get the launcher (java_md_solinux.c) to add the path to libjvm.so to LD_LIBRARY_PATH, but to only do so if running/building for musl. Here?s the comment I added to java_md_solinux.c, which hopefully explains why this is needed: >> >> /* >> * The musl library loader requires LD_LIBRARY_PATH to be set in >> * order to correctly resolve the dependency libjava.so has on libjvm.so. > > I had not realized that the dynamic loader was part of libc. I had assumed it was part of the OS proper. > >> * >> * Specifically, it differs from glibc in the sense that even if >> * libjvm.so has already been loaded it will not be considered a >> * candidate for resolving the dependency unless the *full* path >> * of the already loaded library matches the dependency being loaded. >> * >> * libjvm.so is being loaded by the launcher using a long path to >> * dlopen, not just the basename of the library. Typically this >> * is something like "../lib/server/libjvm.so". However, if/when >> * libjvm.so later tries to dlopen libjava.so (which it does in >> * order to get access to a few functions implemented in >> * libjava.so) the musl loader will, as part of loading >> * dependent libraries, try to load libjvm.so using only its >> * basename "libjvm.so". Since this does not match the longer >> * path path it was first loaded with, the already loaded >> * library is not considered a candidate, and the loader will >> * instead look for libjvm.so elsewhere. If it's not in >> * LD_LIBRARY_PATH the dependency load will fail, and libjava.so >> * will therefore fail as well. >> */ >> Since there is no way to know at runtime that musl is being used, and there is no ?system? compile time define to base the decision on, this change adds support to the JDK build system to set up a OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, passing in the value to java_md_solinux.c as a compiler define -DCLIB=???, using that define to check for musl in RequiresSetenv, and returning true to force the setting of LD_LIBRARY_PATH if there?s a match. > > But we can infer we are using musl if we don't get any glibc version information. We could. I?m not a fan of having !glibc imply musl though. Like, at all. Not saying you can?t change my mind, but you?ll have to work on it :) Cheers, Mikael From david.holmes at oracle.com Wed Apr 12 05:51:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Apr 2017 15:51:06 +1000 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> Message-ID: <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> On 12/04/2017 3:23 PM, Mikael Vidstedt wrote: > >> On Apr 11, 2017, at 8:55 PM, David Holmes wrote: >> >> On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: >>> >>> This one is a big tricky: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ >>> >>> The end goal is to get the launcher (java_md_solinux.c) to add the path to libjvm.so to LD_LIBRARY_PATH, but to only do so if running/building for musl. Here?s the comment I added to java_md_solinux.c, which hopefully explains why this is needed: >>> >>> /* >>> * The musl library loader requires LD_LIBRARY_PATH to be set in >>> * order to correctly resolve the dependency libjava.so has on libjvm.so. >> >> I had not realized that the dynamic loader was part of libc. I had assumed it was part of the OS proper. >> >>> * >>> * Specifically, it differs from glibc in the sense that even if >>> * libjvm.so has already been loaded it will not be considered a >>> * candidate for resolving the dependency unless the *full* path >>> * of the already loaded library matches the dependency being loaded. >>> * >>> * libjvm.so is being loaded by the launcher using a long path to >>> * dlopen, not just the basename of the library. Typically this >>> * is something like "../lib/server/libjvm.so". However, if/when >>> * libjvm.so later tries to dlopen libjava.so (which it does in >>> * order to get access to a few functions implemented in >>> * libjava.so) the musl loader will, as part of loading >>> * dependent libraries, try to load libjvm.so using only its >>> * basename "libjvm.so". Since this does not match the longer >>> * path path it was first loaded with, the already loaded >>> * library is not considered a candidate, and the loader will >>> * instead look for libjvm.so elsewhere. If it's not in >>> * LD_LIBRARY_PATH the dependency load will fail, and libjava.so >>> * will therefore fail as well. >>> */ >>> Since there is no way to know at runtime that musl is being used, and there is no ?system? compile time define to base the decision on, this change adds support to the JDK build system to set up a OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, passing in the value to java_md_solinux.c as a compiler define -DCLIB=???, using that define to check for musl in RequiresSetenv, and returning true to force the setting of LD_LIBRARY_PATH if there?s a match. >> >> But we can infer we are using musl if we don't get any glibc version information. > > > We could. I?m not a fan of having !glibc imply musl though. Like, at all. Not saying you can?t change my mind, but you?ll have to work on it :) Until we support some other non-glibc library it seems like a pretty safe bet! But as discussed on IM the VM knowing it is on musl doesn't help. The problem is that the launcher loaded a specific libjvm by path (client, server, minimal) and libjava has a dependency on libjvm but with no location info. libjvm is not in any of the ld search locations, hence the musl loader won't find it, as it doesn't consider the already loaded libjvm to be a candidate. Short term solution - hack LD_LIBRARY_PATH in launcher. BTW is what we are seeing with musl the same as what happens on AIX: /* We always have to set the LIBPATH on AIX because ld doesn't support $ORIGIN. */ ?? Long term solution ... use a single unified DSO for java and the jvm (and jli?) and dispense with JREs that contain multiple VMs. Cheers, David > Cheers, > Mikael > From erik.joelsson at oracle.com Wed Apr 12 08:27:44 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Apr 2017 10:27:44 +0200 Subject: Welcome to Portola! In-Reply-To: <6982BDF9-5229-476A-9E0E-98DCB2F78CE9@oracle.com> References: <6982BDF9-5229-476A-9E0E-98DCB2F78CE9@oracle.com> Message-ID: <4d2bf943-1fff-3893-397c-76cd988558e8@oracle.com> The reviews posted so far look ok to me. Nothing to add for now. /Erik On 2017-04-11 23:24, Mikael Vidstedt wrote: > All, > > Welcome to the Portola project! From the CFV: > > "This Project will provide a port of the JDK to the Alpine Linux distribution, and in particular the "musl" C library.? > > I have done some initial work getting the JDK to build and run on musl. Over the next few days I will work on getting those changes pushed to the portola/portola forest[1], which is based on jdk10/jdk10 [2]. I updated the portola forest from jdk10 yesterday. > > In total I have around 15 changes, which come in roughly the following flavors: > > * JDK build system support (~5 changes) > * Straightforward/trivial code changes (~8 changes) > * Actual bug fixes/slightly more involved changes (~2 changes) > > Note: I?m not planning on pushing these changes in any particular order, they?re all needed for a successful/working JDK. > > You will find that most of the code changes are not musl specific. Rather, they are effectively adjusting the existing code to be more portable. There is one notable exceptions to this, which I?ll describe more in the corresponding RFR. > > The Portola project is set up to use the ?commit first, review later? policy, meaning the changes are *not* expected to go into the JDK repositories without some additional polishing work. That said, my plan is to push the change *and* send out a corresponding review email *in parallel*. Please help me review the changes and verifying their sanity. When needed, based on reviews/feedback/etc., additional changes can be made. > > Let me know if you have any questions, and please help me with the reviews! > > Cheers, > Mikael > > [1] http://hg.openjdk.java.net/portola/portola > [2] http://hg.openjdk.java.net/jdk10/jdk10/ > From magnus.ihse.bursie at oracle.com Wed Apr 12 09:47:33 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 11:47:33 +0200 Subject: RFR: Remove sys/ prefix from poll.h/signal.h includes In-Reply-To: <3724BBC4-5016-495A-A4CA-3FD8E6F2A375@oracle.com> References: <3724BBC4-5016-495A-A4CA-3FD8E6F2A375@oracle.com> Message-ID: <8df5b25e-40ad-b057-b6a4-ec300e1b5268@oracle.com> On 2017-04-12 00:42, Mikael Vidstedt wrote: > In several places in the JDK sources poll.h and signal.h are included through sys/{poll.h,signal.h}. The posix spec says the files should be included without the sys/ prefix, and musl issues a warning when sys/{poll.h,signal.h} are included. > > This change simple removes the sys/ prefix in all the relevant places. I?ve tried my best to verify that this works on all the platforms/toolchains I have access to, and also got help from the SAP guys to verify that it should work on AIX as well. > > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/pollsignal/webrev.00/hotspot/webrev/ > jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/pollsignal/webrev.00/jdk/webrev/ > > Cheers, > Mikael > LGTM. /Magnus From magnus.ihse.bursie at oracle.com Wed Apr 12 09:52:06 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 11:52:06 +0200 Subject: RFR: Use isnan instead of isnanf In-Reply-To: <60d5e494-e934-9db6-76fa-183ace63eb62@oracle.com> References: <88A94D3B-AE97-42BB-8F90-34EF1E6B316F@oracle.com> <60d5e494-e934-9db6-76fa-183ace63eb62@oracle.com> Message-ID: On 2017-04-12 02:30, David Holmes wrote: > Hi Mikael, > > On 12/04/2017 9:04 AM, Mikael Vidstedt wrote: >> >> isnanf is not available in musl. posix says that isnan handles both >> float and double arguments (typically through a macro checking the >> size of the operand and delegation to the corresponding/actual isnan >> primitive). >> >> This change makes the two JDK wrapper macros call isnan instead of >> isnanf. I?ve tried to verify that the toolchains I have access to >> does the Right(tm) thing for float, but additional >> verification/testing is probably warranted before this is ?productized?. >> >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/hotspot/webrev/ >> jdk: >> http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/jdk/webrev/ > > Are we building with C99 support enabled? No, we are not. In fact, on Solaris, we build with c99 explicitly off. We probably *should* move to C99 in JDK 10, but that is (perhaps?) another story. /Magnus > > The feature test macros are shown as: > > isnan(): > _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE || _ISOC99_SOURCE || > _POSIX_C_SOURCE >= 200112L; > or cc -std=c99 > > isnanf(), isnanl(): > _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 > > On linux we don't seem to do anything to explicitly enable access to > either of these ?? > > Thanks, > David > >> Cheers, >> Mikael >> From magnus.ihse.bursie at oracle.com Wed Apr 12 09:53:35 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 11:53:35 +0200 Subject: RFR: Add limited support for -musl to config.sub In-Reply-To: References: Message-ID: On 2017-04-12 01:14, Mikael Vidstedt wrote: > The version of autoconfig-config.sub checked into the JDK repo is old enough to not support/handle musl. This change adds (very) limited support for handling musl tuples. Specifically, it *only* handles the exact tuple 'x86_64-unknown-linux-musl' and handles it by returning the exact same tuple string. That's how we're doin' things 'round 'ere. ;-) LGTM. /Magnus > > This clearly needs to be made more flexible going forward, and I?m following up on options to do so. Meanwhile, this at least works well enough to get something building. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/configsub/webrev.00/webrev/ > > Cheers, > Mikael > From magnus.ihse.bursie at oracle.com Wed Apr 12 09:54:17 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 11:54:17 +0200 Subject: RFR: Remove execinfo debug code from XToolkit.c In-Reply-To: <4C391CDA-715A-48DE-87A9-41DEDE6ECB93@oracle.com> References: <4C391CDA-715A-48DE-87A9-41DEDE6ECB93@oracle.com> Message-ID: On 2017-04-12 01:23, Mikael Vidstedt wrote: > XToolkit.c has some linux specific debug code in it which is effectively dead. The debug code depends on backtracing functionality from execinfo.h, but musl does not implement/support execinfo.h. > > Since the code is dead, I chose to remove it. In case it turns out that this debugging code gets used a lot when chasing down bugs etc. we?ll have to look at how to support it on musl, or perhaps only enable it if execinfo.h is available. > > http://cr.openjdk.java.net/~mikael/webrevs/portola/execinfo/webrev.00/jdk/webrev/ > > Cheers, > Mikael > LGTM. /Magnus From magnus.ihse.bursie at oracle.com Wed Apr 12 10:04:01 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 12:04:01 +0200 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> <937ccb3f-4af5-0564-d8a9-57515578f192@oracle.com> Message-ID: On 2017-04-12 04:49, Mikael Vidstedt wrote: >> On Apr 11, 2017, at 7:43 PM, David Holmes wrote: >> >> >> >> On 12/04/2017 12:06 PM, Mikael Vidstedt wrote: >>>> On Apr 11, 2017, at 6:58 PM, David Holmes >>>> >> wrote: >>>> >>>> On 12/04/2017 11:42 AM, Mikael Vidstedt wrote: >>>>>> On Apr 11, 2017, at 6:27 PM, David Holmes >>>>>> >> wrote: >>>>>> >>>>>> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >>>>>>> During bootstrapping, os::Linux::libpthread_init() tries to >>>>>>> discover the versions of (g)libc and libpthread respectively. This >>>>>>> is done using confstr(3). However, musl doesn?t implement support >>>>>>> for version discovery, so confstr will return 0/EINVAL. >>>>>>> >>>>>>> This change makes the code handle confstr failures gracefully, and >>>>>>> defaults using the string ?unknown? if the version information >>>>>>> cannot be looked up. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ >>>>>> There was no need to separate out the declaration here: >>>>>> >>>>>> 504 size_t n; >>>>>> 505 >>>>>> 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); >>>>>> >>>>>> Overall I don't think this change is quite what we would want in >>>>>> that it is wrong to print "unknown" when in fact there is no libc >>>>>> (or libpthread?) involved. And we would surely want to see that we >>>>>> are using musl. >>>>> Since the variable is reused for the second confstr call I prefer to >>>>> declare it separately. >>>> Declaring uninitialized variables is an anachronism IMHO. :) >>>> >>>>> In an upcoming change I have added support for adding ?-musl? to the >>>>> (internal) version string so that we can at least see that it?s a >>>>> musl VM instead of a glibc one. >>>>> >>>>> There is a libc - musl. libpthread happens to be part of that same >>>>> libc instead of being a separate library, so depending on how you >>>>> look at it there is or isn?t a libpthread (it is effectively an >>>>> implementation detail of musl). The problem is that there?s no way of >>>>> getting the version information at runtime with musl... >>>> So if we can detect that we are musl then the libc version should be >>>> "musl" and the libpthread version should be "" (or >>>> something like that. >>> That?s fair. My upcoming change will pass in the target C library as an >>> explicit compiler define. Detecting it at runtime is AFAICT not >>> possible. Once I have the change in place I can go back and update the >>> values of these two ?versions?. >>> >>>> I'm surprised there is no mechanism at all for runtime detection of musl! >>>> >>>> But musl defines in unistd.h >>>> >>>> #define _CS_GNU_LIBC_VERSION2 >>>> #define _CS_GNU_LIBPTHREAD_VERSION3 >>>> >>>> so won't those be reported by confstr ?? >>> Unfortunately not. confstr will return 0/EINVAL for almost all >>> arguments. Those two defines are likely only there to make code compile >>> at all with musl, but if confstr is actually called at runtime with any >>> of those values it will return an error. >> I can not make any sense out of: >> >> https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c >> >> Quality code - love the clear explanatory comments. :( > I?ve stared at that one before wondering what the second if statement is trying to express, but in either case it?s not going to return anything useful :) Clearly, it's checking if name &~ 4U is not equal to -1, and if name minus _CS_POSIX_V6_ILP32_OFF32_CFLAGS is greater than 33U. I thought you were a master at C programming. ;-) (Thanks for the laugh of today...) /Magnus > > Cheers, > Mikael > >> David >> >>> Cheers, >>> Mikael >>> >>>> Thanks, >>>> David >>>> >>>>> Cheers, >>>>> Mikael From magnus.ihse.bursie at oracle.com Wed Apr 12 10:25:22 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 12:25:22 +0200 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> Message-ID: On 2017-04-12 04:35, Mikael Vidstedt wrote: > This one is a big tricky: > > http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ > > The end goal is to get the launcher (java_md_solinux.c) to add the path to libjvm.so to LD_LIBRARY_PATH, but to only do so if running/building for musl. Here?s the comment I added to java_md_solinux.c, which hopefully explains why this is needed: > > /* > * The musl library loader requires LD_LIBRARY_PATH to be set in > * order to correctly resolve the dependency libjava.so has on libjvm.so. > * > * Specifically, it differs from glibc in the sense that even if > * libjvm.so has already been loaded it will not be considered a > * candidate for resolving the dependency unless the *full* path > * of the already loaded library matches the dependency being loaded. > * > * libjvm.so is being loaded by the launcher using a long path to > * dlopen, not just the basename of the library. Typically this > * is something like "../lib/server/libjvm.so". However, if/when > * libjvm.so later tries to dlopen libjava.so (which it does in > * order to get access to a few functions implemented in > * libjava.so) the musl loader will, as part of loading > * dependent libraries, try to load libjvm.so using only its > * basename "libjvm.so". Since this does not match the longer > * path path it was first loaded with, the already loaded > * library is not considered a candidate, and the loader will > * instead look for libjvm.so elsewhere. If it's not in > * LD_LIBRARY_PATH the dependency load will fail, and libjava.so > * will therefore fail as well. > */ > Since there is no way to know at runtime that musl is being used, and there is no ?system? compile time define to base the decision on, this change adds support to the JDK build system to set up a OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, passing in the value to java_md_solinux.c as a compiler define -DCLIB=???, using that define to check for musl in RequiresSetenv, and returning true to force the setting of LD_LIBRARY_PATH if there?s a match. > > Definitely could use some feedback on this one. Finally, something that's not just nice cleanups that I can shoot down! ;-) This issue touches two messy areas: 1) The LD_LIBRARY_PATH. There's a lot of hand-waving and dark ritual magic around the loading of libraries in our code. The entire RequiresSetenv seems ... like, eh, the world would be a better place if it didn't exist. I wonder if part of the reason it exists and looks so problematic is due to that we compile our native libraries with incorrect flags. Wouldn't surprise me. 2) Describing platforms with more detail than just os-cpu. You are in effect turning OS_CPU into OS+CLIB_CPU, but it feels a bit too much add-on. If we don't have a specified CLIB, you leave it empty. Perhaps having "platform" or "native" or "default" in other cases? I don't like empty values. Another approach, don't know if it's good or bad, is to reuse the "OPENJDK_[BUILD/TARGET]_OS_ENV". Originally used to distinguish cygwin from msys on Windows, it is now also used (in the BSD port only, not integrated into mainline) to distinguish between free/net/open BSD. So it's more of a "sub-OS specification". (Yeah, the name ENV is perhaps not ideal). In a way, I think the clib distinction (glibc vs musl) is sort-of a similar question. That is, in some circumstances you must be able to differ between "windows" (in general) from "windows.cygwin" or "windows.msys", or "bsd" (in general) from "bsd.freebsd" or whatever. And sometimes, you need to differ between "linux" (in general) from "linux.glibc" or "linux.musl". /Magnus > > Cheers, > Mikael > From kumar.x.srinivasan at oracle.com Wed Apr 12 14:01:17 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 12 Apr 2017 07:01:17 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> Message-ID: <58EE332D.6070801@oracle.com> On 4/12/2017 3:25 AM, Magnus Ihse Bursie wrote: > > On 2017-04-12 04:35, Mikael Vidstedt wrote: >> This one is a big tricky: >> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ >> >> >> The end goal is to get the launcher (java_md_solinux.c) to add the >> path to libjvm.so to LD_LIBRARY_PATH, but to only do so if >> running/building for musl. Here?s the comment I added to >> java_md_solinux.c, which hopefully explains why this is needed: >> >> /* >> * The musl library loader requires LD_LIBRARY_PATH to be set in >> * order to correctly resolve the dependency libjava.so has on >> libjvm.so. >> * >> * Specifically, it differs from glibc in the sense that even if >> * libjvm.so has already been loaded it will not be considered a >> * candidate for resolving the dependency unless the *full* path >> * of the already loaded library matches the dependency being >> loaded. >> * >> * libjvm.so is being loaded by the launcher using a long path to >> * dlopen, not just the basename of the library. Typically this >> * is something like "../lib/server/libjvm.so". However, if/when >> * libjvm.so later tries to dlopen libjava.so (which it does in >> * order to get access to a few functions implemented in >> * libjava.so) the musl loader will, as part of loading >> * dependent libraries, try to load libjvm.so using only its >> * basename "libjvm.so". Since this does not match the longer >> * path path it was first loaded with, the already loaded >> * library is not considered a candidate, and the loader will >> * instead look for libjvm.so elsewhere. If it's not in >> * LD_LIBRARY_PATH the dependency load will fail, and libjava.so >> * will therefore fail as well. >> */ >> Since there is no way to know at runtime that musl is being used, and >> there is no ?system? compile time define to base the decision on, >> this change adds support to the JDK build system to set up a >> OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, >> passing in the value to java_md_solinux.c as a compiler define >> -DCLIB=???, using that define to check for musl in RequiresSetenv, >> and returning true to force the setting of LD_LIBRARY_PATH if there?s >> a match. >> >> Definitely could use some feedback on this one. > Finally, something that's not just nice cleanups that I can shoot > down! ;-) > > This issue touches two messy areas: > > 1) The LD_LIBRARY_PATH. > > There's a lot of hand-waving and dark ritual magic around the loading > of libraries in our code. The entire RequiresSetenv seems ... like, eh, RequiresSetenv was added to solve rt linking issues, take for instance ant running jdk6 (which sets LD_LIBRARY_PATH to its own versions of libjvm.so ) and execs jdk7, jdk8, jdk9 ? Want to take a guess what happens in this case ? ;) So this (RequiresSetenv) was intended to be a temporary fix, ie. until users move to newer JDKs without the LLP requirement, but with this project and AIX purging LLP might get even more distant. Kumar > the world would be a better place if it didn't exist. I wonder if part > of the reason it exists and looks so problematic is due to that we > compile our native libraries with incorrect flags. Wouldn't surprise me. > > 2) Describing platforms with more detail than just os-cpu. > > You are in effect turning OS_CPU into OS+CLIB_CPU, but it feels a bit > too much add-on. If we don't have a specified CLIB, you leave it > empty. Perhaps having "platform" or "native" or "default" in other > cases? I don't like empty values. > > Another approach, don't know if it's good or bad, is to reuse the > "OPENJDK_[BUILD/TARGET]_OS_ENV". Originally used to distinguish cygwin > from msys on Windows, it is now also used (in the BSD port only, not > integrated into mainline) to distinguish between free/net/open BSD. So > it's more of a "sub-OS specification". (Yeah, the name ENV is perhaps > not ideal). In a way, I think the clib distinction (glibc vs musl) is > sort-of a similar question. That is, in some circumstances you must be > able to differ between "windows" (in general) from "windows.cygwin" or > "windows.msys", or "bsd" (in general) from "bsd.freebsd" or whatever. > And sometimes, you need to differ between "linux" (in general) from > "linux.glibc" or "linux.musl". > > /Magnus > >> >> Cheers, >> Mikael >> > From kumar.x.srinivasan at oracle.com Wed Apr 12 14:20:37 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 12 Apr 2017 07:20:37 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> Message-ID: <58EE37B5.9030907@oracle.com> I don't like all the conditionals in that launcher code, and I don't have a good answer to solve this either. If we have to, go for it, but maybe group all those platforms which need LLP under one conditional ? and make that code more readable. Kumar > On 12/04/2017 3:23 PM, Mikael Vidstedt wrote: >> >>> On Apr 11, 2017, at 8:55 PM, David Holmes >>> wrote: >>> >>> On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: >>>> >>>> This one is a big tricky: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/ >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/ >>>> >>>> >>>> The end goal is to get the launcher (java_md_solinux.c) to add the >>>> path to libjvm.so to LD_LIBRARY_PATH, but to only do so if >>>> running/building for musl. Here?s the comment I added to >>>> java_md_solinux.c, which hopefully explains why this is needed: >>>> >>>> /* >>>> * The musl library loader requires LD_LIBRARY_PATH to be set in >>>> * order to correctly resolve the dependency libjava.so has on >>>> libjvm.so. >>> >>> I had not realized that the dynamic loader was part of libc. I had >>> assumed it was part of the OS proper. >>> >>>> * >>>> * Specifically, it differs from glibc in the sense that even if >>>> * libjvm.so has already been loaded it will not be considered a >>>> * candidate for resolving the dependency unless the *full* path >>>> * of the already loaded library matches the dependency being >>>> loaded. >>>> * >>>> * libjvm.so is being loaded by the launcher using a long path to >>>> * dlopen, not just the basename of the library. Typically this >>>> * is something like "../lib/server/libjvm.so". However, if/when >>>> * libjvm.so later tries to dlopen libjava.so (which it does in >>>> * order to get access to a few functions implemented in >>>> * libjava.so) the musl loader will, as part of loading >>>> * dependent libraries, try to load libjvm.so using only its >>>> * basename "libjvm.so". Since this does not match the longer >>>> * path path it was first loaded with, the already loaded >>>> * library is not considered a candidate, and the loader will >>>> * instead look for libjvm.so elsewhere. If it's not in >>>> * LD_LIBRARY_PATH the dependency load will fail, and libjava.so >>>> * will therefore fail as well. >>>> */ >>>> Since there is no way to know at runtime that musl is being used, >>>> and there is no ?system? compile time define to base the decision >>>> on, this change adds support to the JDK build system to set up a >>>> OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, >>>> passing in the value to java_md_solinux.c as a compiler define >>>> -DCLIB=???, using that define to check for musl in RequiresSetenv, >>>> and returning true to force the setting of LD_LIBRARY_PATH if >>>> there?s a match. >>> >>> But we can infer we are using musl if we don't get any glibc version >>> information. >> >> >> We could. I?m not a fan of having !glibc imply musl though. Like, at >> all. Not saying you can?t change my mind, but you?ll have to work on >> it :) > > Until we support some other non-glibc library it seems like a pretty > safe bet! > > But as discussed on IM the VM knowing it is on musl doesn't help. The > problem is that the launcher loaded a specific libjvm by path (client, > server, minimal) and libjava has a dependency on libjvm but with no > location info. libjvm is not in any of the ld search locations, hence > the musl loader won't find it, as it doesn't consider the already > loaded libjvm to be a candidate. > > Short term solution - hack LD_LIBRARY_PATH in launcher. > > BTW is what we are seeing with musl the same as what happens on AIX: > > /* We always have to set the LIBPATH on AIX because ld doesn't support > $ORIGIN. */ > > ?? > > Long term solution ... use a single unified DSO for java and the jvm > (and jli?) and dispense with JREs that contain multiple VMs. > > Cheers, > David > >> Cheers, >> Mikael >> From poonam.bajaj at oracle.com Wed Apr 12 17:55:34 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Wed, 12 Apr 2017 10:55:34 -0700 (PDT) Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <58EE37B5.9030907@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> <58EE37B5.9030907@oracle.com> Message-ID: <1cee5f9d-c96b-43ac-b82e-39380fe9b919@default> What is the cost and implications of always setting LD_LIBRARY_PATH on all linux flavors rather than adding all these conditional for different linux distributions and C libraries? And rather than checking for the musl library (and having these variables passed around), can't we check if we are running on Alpine Linux, similar to the check we perform for AIX: 244#ifdef AIX 245 /* We always have to set the LIBPATH on AIX because ld doesn't support $ORIGIN. */ 246 return JNI_TRUE; 247#endif Why can't we have something like: #ifdef ALPINE /* We always have to set the LIBPATH on ALPINE*/ return JNI_TRUE; #endif Thanks, Poonam > -----Original Message----- > From: Kumar Srinivasan > Sent: Wednesday, April 12, 2017 7:21 AM > To: David Holmes; Mikael Vidstedt > Cc: portola-dev at openjdk.java.net > Subject: Re: RFR: Force setting LD_LIBRARY_PATH in launcher > > > I don't like all the conditionals in that launcher code, and I don't > have a good answer to solve this either. If we have to, go for it, but > maybe group all those platforms which need LLP under one conditional ? > and make that code more readable. > > Kumar > > > On 12/04/2017 3:23 PM, Mikael Vidstedt wrote: > >> > >>> On Apr 11, 2017, at 8:55 PM, David Holmes > >>> wrote: > >>> > >>> On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: > >>>> > >>>> This one is a big tricky: > >>>> > >>>> > http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr > >>>> ev.00/webrev/ > >>>> > >>>> > http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr > >>>> ev.00/jdk/webrev/ > >>>> > >>>> > >>>> The end goal is to get the launcher (java_md_solinux.c) to add the > >>>> path to libjvm.so to LD_LIBRARY_PATH, but to only do so if > >>>> running/building for musl. Here?s the comment I added to > >>>> java_md_solinux.c, which hopefully explains why this is needed: > >>>> > >>>> /* > >>>> * The musl library loader requires LD_LIBRARY_PATH to be set > in > >>>> * order to correctly resolve the dependency libjava.so has > on > >>>> libjvm.so. > >>> > >>> I had not realized that the dynamic loader was part of libc. I had > >>> assumed it was part of the OS proper. > >>> > >>>> * > >>>> * Specifically, it differs from glibc in the sense that even > if > >>>> * libjvm.so has already been loaded it will not be > considered a > >>>> * candidate for resolving the dependency unless the *full* > path > >>>> * of the already loaded library matches the dependency being > >>>> loaded. > >>>> * > >>>> * libjvm.so is being loaded by the launcher using a long > path to > >>>> * dlopen, not just the basename of the library. Typically > this > >>>> * is something like "../lib/server/libjvm.so". However, > if/when > >>>> * libjvm.so later tries to dlopen libjava.so (which it does > in > >>>> * order to get access to a few functions implemented in > >>>> * libjava.so) the musl loader will, as part of loading > >>>> * dependent libraries, try to load libjvm.so using only its > >>>> * basename "libjvm.so". Since this does not match the longer > >>>> * path path it was first loaded with, the already loaded > >>>> * library is not considered a candidate, and the loader will > >>>> * instead look for libjvm.so elsewhere. If it's not in > >>>> * LD_LIBRARY_PATH the dependency load will fail, and > libjava.so > >>>> * will therefore fail as well. > >>>> */ > >>>> Since there is no way to know at runtime that musl is being used, > >>>> and there is no ?system? compile time define to base the decision > >>>> on, this change adds support to the JDK build system to set up a > >>>> OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, > >>>> passing in the value to java_md_solinux.c as a compiler define > >>>> -DCLIB=???, using that define to check for musl in RequiresSetenv, > >>>> and returning true to force the setting of LD_LIBRARY_PATH if > >>>> there?s a match. > >>> > >>> But we can infer we are using musl if we don't get any glibc > version > >>> information. > >> > >> > >> We could. I?m not a fan of having !glibc imply musl though. Like, at > >> all. Not saying you can?t change my mind, but you?ll have to work on > >> it :) > > > > Until we support some other non-glibc library it seems like a pretty > > safe bet! > > > > But as discussed on IM the VM knowing it is on musl doesn't help. The > > problem is that the launcher loaded a specific libjvm by path > (client, > > server, minimal) and libjava has a dependency on libjvm but with no > > location info. libjvm is not in any of the ld search locations, hence > > the musl loader won't find it, as it doesn't consider the already > > loaded libjvm to be a candidate. > > > > Short term solution - hack LD_LIBRARY_PATH in launcher. > > > > BTW is what we are seeing with musl the same as what happens on AIX: > > > > /* We always have to set the LIBPATH on AIX because ld doesn't > support > > $ORIGIN. */ > > > > ?? > > > > Long term solution ... use a single unified DSO for java and the jvm > > (and jli?) and dispense with JREs that contain multiple VMs. > > > > Cheers, > > David > > > >> Cheers, > >> Mikael > >> > From kumar.x.srinivasan at oracle.com Wed Apr 12 19:33:14 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 12 Apr 2017 12:33:14 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <1cee5f9d-c96b-43ac-b82e-39380fe9b919@default> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> <58EE37B5.9030907@oracle.com> <1cee5f9d-c96b-43ac-b82e-39380fe9b919@default> Message-ID: <58EE80FA.6080104@oracle.com> On 4/12/2017 10:55 AM, Poonam Parhar wrote: > What is the cost and implications of always setting LD_LIBRARY_PATH on all linux flavors rather than adding all these conditional for different linux distributions and C libraries? No no!, we don't want to do that ie. set LLP unconditionally, see https://bugs.openjdk.java.net/browse/JDK-6367077 Setting the LLP is not merely setting LLP in the environment, IIRC we have to fork/exec java again for the LLP to take effect. If a particular OS needs it then fine so be it, then that variant has to live with all the consequences of LLP being set. Kumar > > And rather than checking for the musl library (and having these variables passed around), can't we check if we are running on Alpine Linux, similar to the check we perform for AIX: > > 244#ifdef AIX > 245 /* We always have to set the LIBPATH on AIX because ld doesn't support $ORIGIN. */ > 246 return JNI_TRUE; > 247#endif > > Why can't we have something like: > > #ifdef ALPINE > /* We always have to set the LIBPATH on ALPINE*/ > return JNI_TRUE; > #endif > > Thanks, > Poonam > >> -----Original Message----- >> From: Kumar Srinivasan >> Sent: Wednesday, April 12, 2017 7:21 AM >> To: David Holmes; Mikael Vidstedt >> Cc: portola-dev at openjdk.java.net >> Subject: Re: RFR: Force setting LD_LIBRARY_PATH in launcher >> >> >> I don't like all the conditionals in that launcher code, and I don't >> have a good answer to solve this either. If we have to, go for it, but >> maybe group all those platforms which need LLP under one conditional ? >> and make that code more readable. >> >> Kumar >> >>> On 12/04/2017 3:23 PM, Mikael Vidstedt wrote: >>>>> On Apr 11, 2017, at 8:55 PM, David Holmes >>>>> wrote: >>>>> >>>>> On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: >>>>>> This one is a big tricky: >>>>>> >>>>>> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr >>>>>> ev.00/webrev/ >>>>>> >>>>>> >> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr >>>>>> ev.00/jdk/webrev/ >>>>>> >>>>>> >>>>>> The end goal is to get the launcher (java_md_solinux.c) to add the >>>>>> path to libjvm.so to LD_LIBRARY_PATH, but to only do so if >>>>>> running/building for musl. Here?s the comment I added to >>>>>> java_md_solinux.c, which hopefully explains why this is needed: >>>>>> >>>>>> /* >>>>>> * The musl library loader requires LD_LIBRARY_PATH to be set >> in >>>>>> * order to correctly resolve the dependency libjava.so has >> on >>>>>> libjvm.so. >>>>> I had not realized that the dynamic loader was part of libc. I had >>>>> assumed it was part of the OS proper. >>>>> >>>>>> * >>>>>> * Specifically, it differs from glibc in the sense that even >> if >>>>>> * libjvm.so has already been loaded it will not be >> considered a >>>>>> * candidate for resolving the dependency unless the *full* >> path >>>>>> * of the already loaded library matches the dependency being >>>>>> loaded. >>>>>> * >>>>>> * libjvm.so is being loaded by the launcher using a long >> path to >>>>>> * dlopen, not just the basename of the library. Typically >> this >>>>>> * is something like "../lib/server/libjvm.so". However, >> if/when >>>>>> * libjvm.so later tries to dlopen libjava.so (which it does >> in >>>>>> * order to get access to a few functions implemented in >>>>>> * libjava.so) the musl loader will, as part of loading >>>>>> * dependent libraries, try to load libjvm.so using only its >>>>>> * basename "libjvm.so". Since this does not match the longer >>>>>> * path path it was first loaded with, the already loaded >>>>>> * library is not considered a candidate, and the loader will >>>>>> * instead look for libjvm.so elsewhere. If it's not in >>>>>> * LD_LIBRARY_PATH the dependency load will fail, and >> libjava.so >>>>>> * will therefore fail as well. >>>>>> */ >>>>>> Since there is no way to know at runtime that musl is being used, >>>>>> and there is no ?system? compile time define to base the decision >>>>>> on, this change adds support to the JDK build system to set up a >>>>>> OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, >>>>>> passing in the value to java_md_solinux.c as a compiler define >>>>>> -DCLIB=???, using that define to check for musl in RequiresSetenv, >>>>>> and returning true to force the setting of LD_LIBRARY_PATH if >>>>>> there?s a match. >>>>> But we can infer we are using musl if we don't get any glibc >> version >>>>> information. >>>> >>>> We could. I?m not a fan of having !glibc imply musl though. Like, at >>>> all. Not saying you can?t change my mind, but you?ll have to work on >>>> it :) >>> Until we support some other non-glibc library it seems like a pretty >>> safe bet! >>> >>> But as discussed on IM the VM knowing it is on musl doesn't help. The >>> problem is that the launcher loaded a specific libjvm by path >> (client, >>> server, minimal) and libjava has a dependency on libjvm but with no >>> location info. libjvm is not in any of the ld search locations, hence >>> the musl loader won't find it, as it doesn't consider the already >>> loaded libjvm to be a candidate. >>> >>> Short term solution - hack LD_LIBRARY_PATH in launcher. >>> >>> BTW is what we are seeing with musl the same as what happens on AIX: >>> >>> /* We always have to set the LIBPATH on AIX because ld doesn't >> support >>> $ORIGIN. */ >>> >>> ?? >>> >>> Long term solution ... use a single unified DSO for java and the jvm >>> (and jli?) and dispense with JREs that contain multiple VMs. >>> >>> Cheers, >>> David >>> >>>> Cheers, >>>> Mikael >>>> From mikael.vidstedt at oracle.com Wed Apr 12 21:16:34 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Apr 2017 14:16:34 -0700 Subject: RFR: Improve macros for libjdwp memory function overrides In-Reply-To: References: <76F97829-6A4A-4864-80F7-AFA9DAD5052E@oracle.com> Message-ID: <52C70910-8A14-4EAD-A8E9-397CDFC335F5@oracle.com> > On Apr 11, 2017, at 6:46 PM, David Holmes wrote: > > On 12/04/2017 11:07 AM, Mikael Vidstedt wrote: >> >> The memory management functions (malloc, free, ?) should not be used directly in the libjdwp library. To catch any incorrect uses of the functions, the is a handful of macros in libjdwp/util.h which override the raw functions with something which will produce a build time error. >> >> Because of some the internal details of how the musl header files work, some system header files get included *after* the macro overrides, and the result is a bunch of (rather confusing) build time errors. I believe what happens is something along the lines of the following: >> >> libjdwp/util.h does this: >> >> #define calloc(p) Do not use this interface. >> >> Later, through some include chain, one of the system header files (sched.h) gets included. It contains some references to calloc, along the lines of: >> >> ... >> void *calloc(size_t, size_t); >> ? >> #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1, CPU_ALLOC_SIZE(n))) >> ... >> >> But since calloc has been redefined to a bunch of individual words/symbols, the result is an error pointing back to the original macro override definition in libjdwp/util.h: >> >> jdk/src/jdk.jdwp.agent/share/native/libjdwp/util.h:42:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'not' >> #define calloc(p,s) Do not use this interface. >> >> In either case, this change updates the macros to use a macro value which will still induce a build time error if the system memory functions are used in libjdwp (something like ?implicit declaration of function ?do_not_use_this_interface_malloc?), but which doesn?t produce a build time error in the normal/happy case. >> >> That said, this change is incomplete/fishy in the sense that there may well be cases where it?s the wrong thing to do. Specifically, the system header files may well expect to be able to do CPU_ALLOC/calloc implicitly, as part of some system function call or something else. I?ve tried to think of alternative solutions, but haven?t come up with anything so far. Taking suggestions, but meanwhile I?ll push this change. > > I would suggest ensuring that util.h is always the last include in the .c files - that will avoid any possible interference with system headers. If that is not possible then I suggest moving this set of defines to a new header file which can be included last. > > The current approach is potentially broken, as you note, if any of the affected system headers actually use the redefined functions in their own macro expansions. I filed https://bugs.openjdk.java.net/browse/JDK-8178688 to track the work of trying to clean this up. Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 12 21:23:06 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Apr 2017 14:23:06 -0700 Subject: RFR: Handle confstr version lookup failures gracefully In-Reply-To: References: <85a2de54-88a3-726f-bbea-cf7bd68daf6f@oracle.com> <90343188-1266-4F57-9A46-DB9418841CD4@oracle.com> <57456d44-9def-db6e-0704-5ba0d7376062@oracle.com> <937ccb3f-4af5-0564-d8a9-57515578f192@oracle.com> Message-ID: > On Apr 12, 2017, at 3:04 AM, Magnus Ihse Bursie wrote: > > On 2017-04-12 04:49, Mikael Vidstedt wrote: >>> On Apr 11, 2017, at 7:43 PM, David Holmes wrote: >>> >>> >>> >>> On 12/04/2017 12:06 PM, Mikael Vidstedt wrote: >>>>> On Apr 11, 2017, at 6:58 PM, David Holmes >>>>> >> wrote: >>>>> >>>>> On 12/04/2017 11:42 AM, Mikael Vidstedt wrote: >>>>>>> On Apr 11, 2017, at 6:27 PM, David Holmes >>>>>>> >> wrote: >>>>>>> >>>>>>> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote: >>>>>>>> During bootstrapping, os::Linux::libpthread_init() tries to >>>>>>>> discover the versions of (g)libc and libpthread respectively. This >>>>>>>> is done using confstr(3). However, musl doesn?t implement support >>>>>>>> for version discovery, so confstr will return 0/EINVAL. >>>>>>>> >>>>>>>> This change makes the code handle confstr failures gracefully, and >>>>>>>> defaults using the string ?unknown? if the version information >>>>>>>> cannot be looked up. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/ >>>>>>> There was no need to separate out the declaration here: >>>>>>> >>>>>>> 504 size_t n; >>>>>>> 505 >>>>>>> 506 n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0); >>>>>>> >>>>>>> Overall I don't think this change is quite what we would want in >>>>>>> that it is wrong to print "unknown" when in fact there is no libc >>>>>>> (or libpthread?) involved. And we would surely want to see that we >>>>>>> are using musl. >>>>>> Since the variable is reused for the second confstr call I prefer to >>>>>> declare it separately. >>>>> Declaring uninitialized variables is an anachronism IMHO. :) >>>>> >>>>>> In an upcoming change I have added support for adding ?-musl? to the >>>>>> (internal) version string so that we can at least see that it?s a >>>>>> musl VM instead of a glibc one. >>>>>> >>>>>> There is a libc - musl. libpthread happens to be part of that same >>>>>> libc instead of being a separate library, so depending on how you >>>>>> look at it there is or isn?t a libpthread (it is effectively an >>>>>> implementation detail of musl). The problem is that there?s no way of >>>>>> getting the version information at runtime with musl... >>>>> So if we can detect that we are musl then the libc version should be >>>>> "musl" and the libpthread version should be "" (or >>>>> something like that. >>>> That?s fair. My upcoming change will pass in the target C library as an >>>> explicit compiler define. Detecting it at runtime is AFAICT not >>>> possible. Once I have the change in place I can go back and update the >>>> values of these two ?versions?. >>>> >>>>> I'm surprised there is no mechanism at all for runtime detection of musl! >>>>> >>>>> But musl defines in unistd.h >>>>> >>>>> #define _CS_GNU_LIBC_VERSION2 >>>>> #define _CS_GNU_LIBPTHREAD_VERSION3 >>>>> >>>>> so won't those be reported by confstr ?? >>>> Unfortunately not. confstr will return 0/EINVAL for almost all >>>> arguments. Those two defines are likely only there to make code compile >>>> at all with musl, but if confstr is actually called at runtime with any >>>> of those values it will return an error. >>> I can not make any sense out of: >>> >>> https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c >>> >>> Quality code - love the clear explanatory comments. :( >> I?ve stared at that one before wondering what the second if statement is trying to express, but in either case it?s not going to return anything useful :) > Clearly, it's checking if name &~ 4U is not equal to -1, and if name minus _CS_POSIX_V6_ILP32_OFF32_CFLAGS is greater than 33U. Ah, of course. Stupid me! > I thought you were a master at C programming. ;-) Not since the accident ;) Cheers, Mikael > > (Thanks for the laugh of today...) > > /Magnus >> >> Cheers, >> Mikael >> >>> David >>> >>>> Cheers, >>>> Mikael >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Cheers, >>>>>> Mikael > From mikael.vidstedt at oracle.com Wed Apr 12 21:42:25 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Apr 2017 14:42:25 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <58EE80FA.6080104@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> <58EE37B5.9030907@oracle.com> <1cee5f9d-c96b-43ac-b82e-39380fe9b919@default> <58EE80FA.6080104@oracle.com> Message-ID: <932ECB02-1CBF-42B5-8000-B256FD147D68@oracle.com> Thanks for all the great feedback. I filed https://bugs.openjdk.java.net/browse/JDK-8178692 to cover the work of trying to clean this up. For now, in the interest of at least making portola build on musl, I will go ahead and push the change. Cheers, Mikael > On Apr 12, 2017, at 12:33 PM, Kumar Srinivasan wrote: > > > On 4/12/2017 10:55 AM, Poonam Parhar wrote: >> What is the cost and implications of always setting LD_LIBRARY_PATH on all linux flavors rather than adding all these conditional for different linux distributions and C libraries? > > No no!, we don't want to do that ie. set LLP unconditionally, > see https://bugs.openjdk.java.net/browse/JDK-6367077 > Setting the LLP is not merely setting LLP in the environment, > IIRC we have to fork/exec java again for the LLP to take effect. > > If a particular OS needs it then fine so be it, then that variant > has to live with all the consequences of LLP being set. > > Kumar > > > >> >> And rather than checking for the musl library (and having these variables passed around), can't we check if we are running on Alpine Linux, similar to the check we perform for AIX: >> >> 244#ifdef AIX >> 245 /* We always have to set the LIBPATH on AIX because ld doesn't support $ORIGIN. */ >> 246 return JNI_TRUE; >> 247#endif >> >> Why can't we have something like: >> >> #ifdef ALPINE >> /* We always have to set the LIBPATH on ALPINE*/ >> return JNI_TRUE; >> #endif >> >> Thanks, >> Poonam >> >>> -----Original Message----- >>> From: Kumar Srinivasan >>> Sent: Wednesday, April 12, 2017 7:21 AM >>> To: David Holmes; Mikael Vidstedt >>> Cc: portola-dev at openjdk.java.net >>> Subject: Re: RFR: Force setting LD_LIBRARY_PATH in launcher >>> >>> >>> I don't like all the conditionals in that launcher code, and I don't >>> have a good answer to solve this either. If we have to, go for it, but >>> maybe group all those platforms which need LLP under one conditional ? >>> and make that code more readable. >>> >>> Kumar >>> >>>> On 12/04/2017 3:23 PM, Mikael Vidstedt wrote: >>>>>> On Apr 11, 2017, at 8:55 PM, David Holmes >>>>>> wrote: >>>>>> >>>>>> On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: >>>>>>> This one is a big tricky: >>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr >>>>>>> ev.00/webrev/ >>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr >>>>>>> ev.00/jdk/webrev/ >>>>>>> >>>>>>> >>>>>>> The end goal is to get the launcher (java_md_solinux.c) to add the >>>>>>> path to libjvm.so to LD_LIBRARY_PATH, but to only do so if >>>>>>> running/building for musl. Here?s the comment I added to >>>>>>> java_md_solinux.c, which hopefully explains why this is needed: >>>>>>> >>>>>>> /* >>>>>>> * The musl library loader requires LD_LIBRARY_PATH to be set >>> in >>>>>>> * order to correctly resolve the dependency libjava.so has >>> on >>>>>>> libjvm.so. >>>>>> I had not realized that the dynamic loader was part of libc. I had >>>>>> assumed it was part of the OS proper. >>>>>> >>>>>>> * >>>>>>> * Specifically, it differs from glibc in the sense that even >>> if >>>>>>> * libjvm.so has already been loaded it will not be >>> considered a >>>>>>> * candidate for resolving the dependency unless the *full* >>> path >>>>>>> * of the already loaded library matches the dependency being >>>>>>> loaded. >>>>>>> * >>>>>>> * libjvm.so is being loaded by the launcher using a long >>> path to >>>>>>> * dlopen, not just the basename of the library. Typically >>> this >>>>>>> * is something like "../lib/server/libjvm.so". However, >>> if/when >>>>>>> * libjvm.so later tries to dlopen libjava.so (which it does >>> in >>>>>>> * order to get access to a few functions implemented in >>>>>>> * libjava.so) the musl loader will, as part of loading >>>>>>> * dependent libraries, try to load libjvm.so using only its >>>>>>> * basename "libjvm.so". Since this does not match the longer >>>>>>> * path path it was first loaded with, the already loaded >>>>>>> * library is not considered a candidate, and the loader will >>>>>>> * instead look for libjvm.so elsewhere. If it's not in >>>>>>> * LD_LIBRARY_PATH the dependency load will fail, and >>> libjava.so >>>>>>> * will therefore fail as well. >>>>>>> */ >>>>>>> Since there is no way to know at runtime that musl is being used, >>>>>>> and there is no ?system? compile time define to base the decision >>>>>>> on, this change adds support to the JDK build system to set up a >>>>>>> OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, >>>>>>> passing in the value to java_md_solinux.c as a compiler define >>>>>>> -DCLIB=???, using that define to check for musl in RequiresSetenv, >>>>>>> and returning true to force the setting of LD_LIBRARY_PATH if >>>>>>> there?s a match. >>>>>> But we can infer we are using musl if we don't get any glibc >>> version >>>>>> information. >>>>> >>>>> We could. I?m not a fan of having !glibc imply musl though. Like, at >>>>> all. Not saying you can?t change my mind, but you?ll have to work on >>>>> it :) >>>> Until we support some other non-glibc library it seems like a pretty >>>> safe bet! >>>> >>>> But as discussed on IM the VM knowing it is on musl doesn't help. The >>>> problem is that the launcher loaded a specific libjvm by path >>> (client, >>>> server, minimal) and libjava has a dependency on libjvm but with no >>>> location info. libjvm is not in any of the ld search locations, hence >>>> the musl loader won't find it, as it doesn't consider the already >>>> loaded libjvm to be a candidate. >>>> >>>> Short term solution - hack LD_LIBRARY_PATH in launcher. >>>> >>>> BTW is what we are seeing with musl the same as what happens on AIX: >>>> >>>> /* We always have to set the LIBPATH on AIX because ld doesn't >>> support >>>> $ORIGIN. */ >>>> >>>> ?? >>>> >>>> Long term solution ... use a single unified DSO for java and the jvm >>>> (and jli?) and dispense with JREs that contain multiple VMs. >>>> >>>> Cheers, >>>> David >>>> >>>>> Cheers, >>>>> Mikael >>>>> > From mikael.vidstedt at oracle.com Wed Apr 12 22:27:39 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Apr 2017 15:27:39 -0700 Subject: RFR: Force setting LD_LIBRARY_PATH in launcher In-Reply-To: <932ECB02-1CBF-42B5-8000-B256FD147D68@oracle.com> References: <7E1068F5-8312-468F-BCE5-E5BA9BE861B4@oracle.com> <6E879A72-D6ED-4E19-AF73-8C7963002A12@oracle.com> <391bf10e-ba31-3b9f-e2e0-ca216ae2ffa9@oracle.com> <58EE37B5.9030907@oracle.com> <1cee5f9d-c96b-43ac-b82e-39380fe9b919@default> <58EE80FA.6080104@oracle.com> <932ECB02-1CBF-42B5-8000-B256FD147D68@oracle.com> Message-ID: <089EC1C2-C0EA-4588-8534-D0C5F71260A3@oracle.com> Actually, I did make one small, final change based on Magnus?s feedback, which is use the value "default? for the build system *_CLIB variables in the cases where they were otherwise left empty. Cheers, Mikael > On Apr 12, 2017, at 2:42 PM, Mikael Vidstedt wrote: > > > Thanks for all the great feedback. I filed https://bugs.openjdk.java.net/browse/JDK-8178692 to cover the work of trying to clean this up. For now, in the interest of at least making portola build on musl, I will go ahead and push the change. > > Cheers, > Mikael > >> On Apr 12, 2017, at 12:33 PM, Kumar Srinivasan wrote: >> >> >> On 4/12/2017 10:55 AM, Poonam Parhar wrote: >>> What is the cost and implications of always setting LD_LIBRARY_PATH on all linux flavors rather than adding all these conditional for different linux distributions and C libraries? >> >> No no!, we don't want to do that ie. set LLP unconditionally, >> see https://bugs.openjdk.java.net/browse/JDK-6367077 >> Setting the LLP is not merely setting LLP in the environment, >> IIRC we have to fork/exec java again for the LLP to take effect. >> >> If a particular OS needs it then fine so be it, then that variant >> has to live with all the consequences of LLP being set. >> >> Kumar >> >> >> >>> >>> And rather than checking for the musl library (and having these variables passed around), can't we check if we are running on Alpine Linux, similar to the check we perform for AIX: >>> >>> 244#ifdef AIX >>> 245 /* We always have to set the LIBPATH on AIX because ld doesn't support $ORIGIN. */ >>> 246 return JNI_TRUE; >>> 247#endif >>> >>> Why can't we have something like: >>> >>> #ifdef ALPINE >>> /* We always have to set the LIBPATH on ALPINE*/ >>> return JNI_TRUE; >>> #endif >>> >>> Thanks, >>> Poonam >>> >>>> -----Original Message----- >>>> From: Kumar Srinivasan >>>> Sent: Wednesday, April 12, 2017 7:21 AM >>>> To: David Holmes; Mikael Vidstedt >>>> Cc: portola-dev at openjdk.java.net >>>> Subject: Re: RFR: Force setting LD_LIBRARY_PATH in launcher >>>> >>>> >>>> I don't like all the conditionals in that launcher code, and I don't >>>> have a good answer to solve this either. If we have to, go for it, but >>>> maybe group all those platforms which need LLP under one conditional ? >>>> and make that code more readable. >>>> >>>> Kumar >>>> >>>>> On 12/04/2017 3:23 PM, Mikael Vidstedt wrote: >>>>>>> On Apr 11, 2017, at 8:55 PM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>> On 12/04/2017 12:35 PM, Mikael Vidstedt wrote: >>>>>>>> This one is a big tricky: >>>>>>>> >>>>>>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr >>>>>>>> ev.00/webrev/ >>>>>>>> >>>>>>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr >>>>>>>> ev.00/jdk/webrev/ >>>>>>>> >>>>>>>> >>>>>>>> The end goal is to get the launcher (java_md_solinux.c) to add the >>>>>>>> path to libjvm.so to LD_LIBRARY_PATH, but to only do so if >>>>>>>> running/building for musl. Here?s the comment I added to >>>>>>>> java_md_solinux.c, which hopefully explains why this is needed: >>>>>>>> >>>>>>>> /* >>>>>>>> * The musl library loader requires LD_LIBRARY_PATH to be set >>>> in >>>>>>>> * order to correctly resolve the dependency libjava.so has >>>> on >>>>>>>> libjvm.so. >>>>>>> I had not realized that the dynamic loader was part of libc. I had >>>>>>> assumed it was part of the OS proper. >>>>>>> >>>>>>>> * >>>>>>>> * Specifically, it differs from glibc in the sense that even >>>> if >>>>>>>> * libjvm.so has already been loaded it will not be >>>> considered a >>>>>>>> * candidate for resolving the dependency unless the *full* >>>> path >>>>>>>> * of the already loaded library matches the dependency being >>>>>>>> loaded. >>>>>>>> * >>>>>>>> * libjvm.so is being loaded by the launcher using a long >>>> path to >>>>>>>> * dlopen, not just the basename of the library. Typically >>>> this >>>>>>>> * is something like "../lib/server/libjvm.so". However, >>>> if/when >>>>>>>> * libjvm.so later tries to dlopen libjava.so (which it does >>>> in >>>>>>>> * order to get access to a few functions implemented in >>>>>>>> * libjava.so) the musl loader will, as part of loading >>>>>>>> * dependent libraries, try to load libjvm.so using only its >>>>>>>> * basename "libjvm.so". Since this does not match the longer >>>>>>>> * path path it was first loaded with, the already loaded >>>>>>>> * library is not considered a candidate, and the loader will >>>>>>>> * instead look for libjvm.so elsewhere. If it's not in >>>>>>>> * LD_LIBRARY_PATH the dependency load will fail, and >>>> libjava.so >>>>>>>> * will therefore fail as well. >>>>>>>> */ >>>>>>>> Since there is no way to know at runtime that musl is being used, >>>>>>>> and there is no ?system? compile time define to base the decision >>>>>>>> on, this change adds support to the JDK build system to set up a >>>>>>>> OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, >>>>>>>> passing in the value to java_md_solinux.c as a compiler define >>>>>>>> -DCLIB=???, using that define to check for musl in RequiresSetenv, >>>>>>>> and returning true to force the setting of LD_LIBRARY_PATH if >>>>>>>> there?s a match. >>>>>>> But we can infer we are using musl if we don't get any glibc >>>> version >>>>>>> information. >>>>>> >>>>>> We could. I?m not a fan of having !glibc imply musl though. Like, at >>>>>> all. Not saying you can?t change my mind, but you?ll have to work on >>>>>> it :) >>>>> Until we support some other non-glibc library it seems like a pretty >>>>> safe bet! >>>>> >>>>> But as discussed on IM the VM knowing it is on musl doesn't help. The >>>>> problem is that the launcher loaded a specific libjvm by path >>>> (client, >>>>> server, minimal) and libjava has a dependency on libjvm but with no >>>>> location info. libjvm is not in any of the ld search locations, hence >>>>> the musl loader won't find it, as it doesn't consider the already >>>>> loaded libjvm to be a candidate. >>>>> >>>>> Short term solution - hack LD_LIBRARY_PATH in launcher. >>>>> >>>>> BTW is what we are seeing with musl the same as what happens on AIX: >>>>> >>>>> /* We always have to set the LIBPATH on AIX because ld doesn't >>>> support >>>>> $ORIGIN. */ >>>>> >>>>> ?? >>>>> >>>>> Long term solution ... use a single unified DSO for java and the jvm >>>>> (and jli?) and dispense with JREs that contain multiple VMs. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >> > From mikael.vidstedt at oracle.com Wed Apr 12 22:29:01 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 22:29:01 +0000 Subject: hg: portola/portola: Force setting LD_LIBRARY_PATH in launcher for musl Message-ID: <201704122229.v3CMT1kF000306@aojmv0008.oracle.com> Changeset: 757c7a9f7304 Author: mikael Date: 2017-04-12 15:26 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/757c7a9f7304 Force setting LD_LIBRARY_PATH in launcher for musl ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in From mikael.vidstedt at oracle.com Wed Apr 12 22:29:07 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 12 Apr 2017 22:29:07 +0000 Subject: hg: portola/portola/jdk: Force setting LD_LIBRARY_PATH in launcher for musl Message-ID: <201704122229.v3CMT7Jp000366@aojmv0008.oracle.com> Changeset: 46372f62cb6a Author: mikael Date: 2017-04-12 15:26 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/46372f62cb6a Force setting LD_LIBRARY_PATH in launcher for musl ! make/lib/CoreLibraries.gmk ! src/java.base/unix/native/libjli/java_md_solinux.c From mikael.vidstedt at oracle.com Wed Apr 12 23:09:18 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Apr 2017 16:09:18 -0700 Subject: RFR: Disable PaX mprotect on executables Message-ID: Alpine by default has PaX [1] enabled. Among other things, PaX tries to prevent various attack vectors by controlling the ways in which page protection can be updated/changed. For example, it does not allow marking previously writable pages as executable. Guess what hotspot likes to do? This change is incomplete, and I could use some help figuring out how to complete it. http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/ Basically, it all comes down to needing to use a tool - paxctl - to mark the executables in a way so that the kernel knows to disable/relax some of the PaX features for the process. The patch adds support for finding the paxctl tool, and for using the tool (if found) to mark the excutable. However, here are two of the main reasons why this patch is incomplete: * There are two different JDKs which may or may not need the special paxctl treatment: buildjdk and target jdk. When building the JDK on Alpine (really: on a PaX enabled system) the buildjdk needs to have its executables marked as well, but when cross compiling that?s not necessarily needed. * The patch currently bases the decision on whether to mark the executables on whether the target CLIB is ?musl?, where in fact that doesn?t really have anything to do with musl * Not all executables necessarily load and run the JVM, so not all of them necessarily need to be marked * It?s not really the user space that decides whether the PaX relaxation is needed - it?s the kernel. That means that when running in, say, Docker, even if the base image would be Alpine (or some other distribution which has PaX enabled by default), it?s really the configuration of the host system kernel which comes into play. I?m not sure what the right solution is here. Taking suggestions. Cheers, Mikael [1] http://pax.grsecurity.net From david.holmes at oracle.com Thu Apr 13 03:18:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 13:18:51 +1000 Subject: RFR: Unaligned pointer dereference crash in ClassFileParser In-Reply-To: <2675F2D9-95FD-438B-8B58-A06B5CCD75DB@oracle.com> References: <2675F2D9-95FD-438B-8B58-A06B5CCD75DB@oracle.com> Message-ID: <5a43c893-5476-5c21-5118-d183cc1cdfa7@oracle.com> Hi Mikael, I really like the cleanup of is_Java_byte_ordering_different to utilize build-time endian information so it can go in shared code. The rest seems okay in principle - I can't really comment on the template details but the overall approach looks quite reasonable. Nit: conjoint_swap_maybe -> conjoint_swap_if_needed Nit: where you changed signatures to return void* instead of u2* you need to realign the arguments lists by 2 spaces. Thanks, David On 12/04/2017 2:55 PM, Mikael Vidstedt wrote: > > This one is interesting, and requires a bit of background. Get yourself a cup of coffee/tea if you haven?t already. I?d actually like to push this this jdk10 as well sometime soon-ish, because it?s an actual/latent bug which may be tickled if our toolchain changes in some way. It?s not actually a musl bug per-se, it just happens to be tickled when compiling for musl. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/portola/copyswapaligned/webrev.00/hotspot/webrev/ > > The story goes something like this: > > x86 is normally very forgiving when it comes to dereferencing unaligned pointers. Even if the pointer isn?t aligned on the natural size of the element being accessed, the hardware will do the Right Thing(tm) and nobody gets hurt. However, turns out there are exceptions to this. Specifically, SSA2 introduced the movdqa instruction, which is a 128-bit load/store which *does* require that the pointer is 128-bit aligned. > > Normally this isn?t a problem, because after all we don?t typically use 128-bit data types in our C/C++ code. However, just because we don?t use any such data types explicitly, there?s nothing preventing the C compiler to do so under the covers. Specifically, the C compiler tends to do loop unrolling and vectorization, which can turn pretty much any data access into vectorized SIMD accesses. > > We?ve actually run into a variation on this exact same problem a while back when upgrading to gcc 4.9.2 [1]. That time the problem was in nio/Bits.c, and it was fixed (by me) by moving the copy functionality into hotspot (copy.[ch]pp), making sure the copy logic does the relevant alignment checks etc. > > This time the problem is with ClassFileParser. Or more accurately, it?s in the methods ClassFileParser makes use of. Specifically, the problem is with the copy_u2_with_conversion method, used to copy various data from the class file and put it in the ?native? endian order in memory. It, in turn, uses Bytes::get_Java_u2 to read and potentially byte swap a 16-bit entry from the class file. bytes_x86.hpp has this to say about its implementation: > > // Efficient reading and writing of unaligned unsigned data in platform-specific byte ordering > // (no special code is needed since x86 CPUs can access unaligned data) > > While that is /almost/ always true for the x86 architecture in itself, the C standard still expects accesses to be aligned, and the C compiler is free to make use of that expectation to, for example, vectorize operations and make use of the movdqa instruction. > > So why is this only a problem when using musl? Turns out it sorta isn?t, but bytes_x86.hpp will, in the end, actually use system library functions to do byte swapping. Specifically, on linux_x86 it will come down to bytes_linux_x86.inline.hpp which, on AMD64, uses the system functions/macros swap_u{16,32,64} to do the actual byte swapping. Now here?s the ?funny? & interesting part: > > With glibc, the swap_u{16,32,64} methods are implemented using inline assembly - in the end it comes down to a rotate ?rorw? instruction. Since GCC can?t see through the inline assembly, it will not realize that there are loop unrolling/vectorization opportunities, and of specific interest to us: the movdqa instruction will not be used. The code will potentially not be as efficient as it could be, but it will be functional. > > With musl, the swap methods are instead implemented as normal macros, shifting bits around to achieve the desired effect. GCC recognizes the bit shifting patterns, will realize that it?s just byte swapping a bunch of values, will vectorize the loop, and *will* make use of the movdqa instruction. Kaboom. > > To recap: dereferencing unaligned pointers in C/C++ is a no-no, even in cases where you think it should be okay. > > > That concludes the background. Let?s move over to the suggested fix. There are (at least) two alternatives: > > 1. Only fix the specific case of classFileStream.cpp/copy_u2_with_conversion > 2. Address the larger problem of Bytes providing methods which may not be safe > > For better or worse, the webrev I linked to above does the latter - it doesn?t just do the minimal change. I?m happy to revisit that and reduce the scope of the patch if needed. > > > The key changes are in three different areas, the first two of which are needed (in one way or another): > > * copy.[ch]pp > > Introducing: conjoint_swap_maybe > > conjoint_swap_maybe will copy data, and bytes wap it on-the-fly if the specified endianness differs from the native/CPU endianness. It does this by either delegating to conjoint_swap (on endian mismatch), or conjoint_copy (on match). In copy.cpp, the changes all boil down to making the innermost do_conjoint_swap method more flexible so that it can be reused for both cases (straight copy as well as copy+swap). > > * classFile{Parser,Stream} > > The key (and only absolutely needed) change is in classFileParser.cpp, switching to copying data from the class file using the new conjoint_swap_maybe method, replacing the loop implemented in copy_u2_with_conversion/Bytes::get_Java_u2. > > However, in addition to that change, I noticed that there are a lot of u2* passed around in the code, pointers which are not necessarily 16-bit aligned. While there?s nothing wrong with *having* an unaligned pointer in C - as long as it?s not dereferenced everything is peachy - it made me uneasy to see it passed around and used the way it is. Specifically, ClassFileStream::get_u2_buffer() could, to the untrained eye, be a bit misleading. One could accidentally and incorrectly assume that the returned pointer is, in fact, 16-bit aligned and start dereferencing it directly, where in fact there is no such guarantee. Perhaps even use it as an array and attract the wrath of the C compiler. > > Changing to void* may or may not be the right thing to do here. In a way I?d actually like to ?carry? the type information, but in some way still prevent the pointer from being directly dereferenced. Taking suggestions. > > > * bytes_x86.hpp > > Note: I believe that given the above changes, this one isn?t absolutely necessary. This is addressing the wider concern that other parts of hotspot may use the same primitives in much the same (potentially broken) way, and in particular the fact that the get/put primitives aren?t checking whether the pointer argument is aligned before they dereference it. It may well be that a simple assert or two would do the trick here. That said: > > It turns out that the various platforms all have their own unique ways of implementing bytes.hpp, duplicating some logic which could/should be platform independent. I tried to clean up and unify it all a bit while at it by introducing an Endian helper class in bytes.hpp. The primitives for accessing data in memory now check for alignment and either perform the raw memory access (when the pointer is aligned), or does a memcpy (if unaligned). There?s some template ?magic? in there avoid duplicating code, but hopefully the magic is relatively straightforward. > > > > Appreciate any and all comments and feedback. As mentioned, I think this is worth pushing to jdk10 as well in some not-all-too-distant future. > > Cheers, > Mikael > > [1] https://bugs.openjdk.java.net/browse/JDK-8141491 > From david.holmes at oracle.com Thu Apr 13 04:36:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 14:36:18 +1000 Subject: RFR: Use isnan instead of isnanf In-Reply-To: References: <88A94D3B-AE97-42BB-8F90-34EF1E6B316F@oracle.com> <60d5e494-e934-9db6-76fa-183ace63eb62@oracle.com> Message-ID: On 12/04/2017 7:52 PM, Magnus Ihse Bursie wrote: > On 2017-04-12 02:30, David Holmes wrote: >> Hi Mikael, >> >> On 12/04/2017 9:04 AM, Mikael Vidstedt wrote: >>> >>> isnanf is not available in musl. posix says that isnan handles both >>> float and double arguments (typically through a macro checking the >>> size of the operand and delegation to the corresponding/actual isnan >>> primitive). >>> >>> This change makes the two JDK wrapper macros call isnan instead of >>> isnanf. I?ve tried to verify that the toolchains I have access to >>> does the Right(tm) thing for float, but additional >>> verification/testing is probably warranted before this is ?productized?. >>> >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/hotspot/webrev/ >>> jdk: >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/jdk/webrev/ >> >> Are we building with C99 support enabled? > No, we are not. In fact, on Solaris, we build with c99 explicitly off. So can someone explain to me how we are able to use these math functions/macros that seem to be guarded with: #ifdef __USE_ISOC99 ?? David ----- > We probably *should* move to C99 in JDK 10, but that is (perhaps?) > another story. > > /Magnus >> >> The feature test macros are shown as: >> >> isnan(): >> _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE || _ISOC99_SOURCE || >> _POSIX_C_SOURCE >= 200112L; >> or cc -std=c99 >> >> isnanf(), isnanl(): >> _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 >> >> On linux we don't seem to do anything to explicitly enable access to >> either of these ?? >> >> Thanks, >> David >> >>> Cheers, >>> Mikael >>> > From david.holmes at oracle.com Thu Apr 13 05:00:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 15:00:27 +1000 Subject: RFR: Disable PaX mprotect on executables In-Reply-To: References: Message-ID: Hi Mikael, On 13/04/2017 9:09 AM, Mikael Vidstedt wrote: > > Alpine by default has PaX [1] enabled. Among other things, PaX tries to prevent various attack vectors by controlling the ways in which page protection can be updated/changed. For example, it does not allow marking previously writable pages as executable. Guess what hotspot likes to do? > > This change is incomplete, and I could use some help figuring out how to complete it. In all seriousness I would not do this. I think it is up to the "deployer" of a JRE on such a system to take whatever PaX related steps are needed to allow the binaries to run. I don't think we should be making any such decisions at build time, nor requiring paxctl be available. All we should do is document what is required. David ----- > http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/ > > Basically, it all comes down to needing to use a tool - paxctl - to mark the executables in a way so that the kernel knows to disable/relax some of the PaX features for the process. The patch adds support for finding the paxctl tool, and for using the tool (if found) to mark the excutable. However, here are two of the main reasons why this patch is incomplete: > > * There are two different JDKs which may or may not need the special paxctl treatment: buildjdk and target jdk. When building the JDK on Alpine (really: on a PaX enabled system) the buildjdk needs to have its executables marked as well, but when cross compiling that?s not necessarily needed. > * The patch currently bases the decision on whether to mark the executables on whether the target CLIB is ?musl?, where in fact that doesn?t really have anything to do with musl > * Not all executables necessarily load and run the JVM, so not all of them necessarily need to be marked > * It?s not really the user space that decides whether the PaX relaxation is needed - it?s the kernel. That means that when running in, say, Docker, even if the base image would be Alpine (or some other distribution which has PaX enabled by default), it?s really the configuration of the host system kernel which comes into play. > > I?m not sure what the right solution is here. Taking suggestions. > > Cheers, > Mikael > > [1] http://pax.grsecurity.net > From mikael.vidstedt at oracle.com Thu Apr 13 05:07:02 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Apr 2017 22:07:02 -0700 Subject: RFR: Use isnan instead of isnanf In-Reply-To: References: <88A94D3B-AE97-42BB-8F90-34EF1E6B316F@oracle.com> <60d5e494-e934-9db6-76fa-183ace63eb62@oracle.com> Message-ID: <534E72F3-902A-45FE-82B7-13D824A78133@oracle.com> Cheers, Mikael > On Apr 12, 2017, at 9:36 PM, David Holmes wrote: > >> On 12/04/2017 7:52 PM, Magnus Ihse Bursie wrote: >>> On 2017-04-12 02:30, David Holmes wrote: >>> Hi Mikael, >>> >>>> On 12/04/2017 9:04 AM, Mikael Vidstedt wrote: >>>> >>>> isnanf is not available in musl. posix says that isnan handles both >>>> float and double arguments (typically through a macro checking the >>>> size of the operand and delegation to the corresponding/actual isnan >>>> primitive). >>>> >>>> This change makes the two JDK wrapper macros call isnan instead of >>>> isnanf. I?ve tried to verify that the toolchains I have access to >>>> does the Right(tm) thing for float, but additional >>>> verification/testing is probably warranted before this is ?productized?. >>>> >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/hotspot/webrev/ >>>> jdk: >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/isnan/webrev.00/jdk/webrev/ >>> >>> Are we building with C99 support enabled? >> No, we are not. In fact, on Solaris, we build with c99 explicitly off. > > So can someone explain to me how we are able to use these math functions/macros that seem to be guarded with: > > #ifdef __USE_ISOC99 > > ?? Well, I guess the answer could well be that before my change we didn't try to, and with my change we may well be using the wrong isnan for floats. Specifically, on platforms other than musl it may well be using the isnan function taking a double argument, implicitly converting the float argument to a double..? I filed https://bugs.openjdk.java.net/browse/JDK-8178689 to follow up on and verify the correctness of that fix. Cheers, Mikael > > David > ----- > >> We probably *should* move to C99 in JDK 10, but that is (perhaps?) >> another story. >> >> /Magnus >>> >>> The feature test macros are shown as: >>> >>> isnan(): >>> _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE || _ISOC99_SOURCE || >>> _POSIX_C_SOURCE >= 200112L; >>> or cc -std=c99 >>> >>> isnanf(), isnanl(): >>> _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 >>> >>> On linux we don't seem to do anything to explicitly enable access to >>> either of these ?? >>> >>> Thanks, >>> David >>> >>>> Cheers, >>>> Mikael >>>> >> From erik.joelsson at oracle.com Thu Apr 13 07:31:12 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Apr 2017 09:31:12 +0200 Subject: RFR: Disable PaX mprotect on executables In-Reply-To: References: Message-ID: On 2017-04-13 07:00, David Holmes wrote: > Hi Mikael, > > On 13/04/2017 9:09 AM, Mikael Vidstedt wrote: >> >> Alpine by default has PaX [1] enabled. Among other things, PaX tries >> to prevent various attack vectors by controlling the ways in which >> page protection can be updated/changed. For example, it does not >> allow marking previously writable pages as executable. Guess what >> hotspot likes to do? >> >> This change is incomplete, and I could use some help figuring out how >> to complete it. > > In all seriousness I would not do this. I think it is up to the > "deployer" of a JRE on such a system to take whatever PaX related > steps are needed to allow the binaries to run. I don't think we should > be making any such decisions at build time, nor requiring paxctl be > available. All we should do is document what is required. > I think we do have to support this. Alpine is the platform we are being asked to support and our bits will be DoA unless this is done. This will get very annoying quickly when trying to test the bits. Unless, of course, we only support and test on alpine in containers. Whichever we do, it needs to be documented. You are correct that this has nothing to do with muscl, so I think it should be controlled with a specific configure flag (--enable-pax?) and it should be default off. We would need to put paxctl in the devkit for the affected platform(s) since it's not default installed on our build platforms today (or create a separate package with it, perhaps easier). In our jib profile configuration we would enable this for the alpine linux builds. Supporting running the build on a PaX enabled system is a different issue. If we want to support this, then we could have configure detect that PaX is currently active (I assume that's possible) and take the necessary precautions to use paxctl on at least the buildjdk, and if not cross compiling, also the target jdk. This would be the only case where the default value of the flag would be true. /Erik > David > ----- > >> http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/ >> >> >> Basically, it all comes down to needing to use a tool - paxctl - to >> mark the executables in a way so that the kernel knows to >> disable/relax some of the PaX features for the process. The patch >> adds support for finding the paxctl tool, and for using the tool (if >> found) to mark the excutable. However, here are two of the main >> reasons why this patch is incomplete: >> >> * There are two different JDKs which may or may not need the special >> paxctl treatment: buildjdk and target jdk. When building the JDK on >> Alpine (really: on a PaX enabled system) the buildjdk needs to have >> its executables marked as well, but when cross compiling that?s not >> necessarily needed. >> * The patch currently bases the decision on whether to mark the >> executables on whether the target CLIB is ?musl?, where in fact that >> doesn?t really have anything to do with musl >> * Not all executables necessarily load and run the JVM, so not all of >> them necessarily need to be marked >> * It?s not really the user space that decides whether the PaX >> relaxation is needed - it?s the kernel. That means that when running >> in, say, Docker, even if the base image would be Alpine (or some >> other distribution which has PaX enabled by default), it?s really the >> configuration of the host system kernel which comes into play. >> >> I?m not sure what the right solution is here. Taking suggestions. >> >> Cheers, >> Mikael >> >> [1] http://pax.grsecurity.net >> From david.holmes at oracle.com Thu Apr 13 08:06:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 18:06:35 +1000 Subject: RFR: Disable PaX mprotect on executables In-Reply-To: References: Message-ID: <7ae33ac7-b44c-c2ed-e065-51282d2c58d7@oracle.com> On 13/04/2017 5:31 PM, Erik Joelsson wrote: > On 2017-04-13 07:00, David Holmes wrote: >> Hi Mikael, >> >> On 13/04/2017 9:09 AM, Mikael Vidstedt wrote: >>> >>> Alpine by default has PaX [1] enabled. Among other things, PaX tries >>> to prevent various attack vectors by controlling the ways in which >>> page protection can be updated/changed. For example, it does not >>> allow marking previously writable pages as executable. Guess what >>> hotspot likes to do? >>> >>> This change is incomplete, and I could use some help figuring out how >>> to complete it. >> >> In all seriousness I would not do this. I think it is up to the >> "deployer" of a JRE on such a system to take whatever PaX related >> steps are needed to allow the binaries to run. I don't think we should >> be making any such decisions at build time, nor requiring paxctl be >> available. All we should do is document what is required. >> > I think we do have to support this. Alpine is the platform we are being > asked to support and our bits will be DoA unless this is done. This will I look at this from the perspective of a security conscious user. If I have chosen a hardened platform, and I am choosing software I want to run on that platform, then I want to decide how/whether security should be relaxed for a given binary - not some third-party (and especially not the third-party that supplied the software that I don't necessarily trust!). > get very annoying quickly when trying to test the bits. Unless, of > course, we only support and test on alpine in containers. Whichever we > do, it needs to be documented. For our own testing I suggest running Alpine with PaX disabled. David ----- > You are correct that this has nothing to do with muscl, so I think it > should be controlled with a specific configure flag (--enable-pax?) and > it should be default off. We would need to put paxctl in the devkit for > the affected platform(s) since it's not default installed on our build > platforms today (or create a separate package with it, perhaps easier). > In our jib profile configuration we would enable this for the alpine > linux builds. > > Supporting running the build on a PaX enabled system is a different > issue. If we want to support this, then we could have configure detect > that PaX is currently active (I assume that's possible) and take the > necessary precautions to use paxctl on at least the buildjdk, and if not > cross compiling, also the target jdk. This would be the only case where > the default value of the flag would be true. > > /Erik > >> David >> ----- >> >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/ >>> >>> >>> Basically, it all comes down to needing to use a tool - paxctl - to >>> mark the executables in a way so that the kernel knows to >>> disable/relax some of the PaX features for the process. The patch >>> adds support for finding the paxctl tool, and for using the tool (if >>> found) to mark the excutable. However, here are two of the main >>> reasons why this patch is incomplete: >>> >>> * There are two different JDKs which may or may not need the special >>> paxctl treatment: buildjdk and target jdk. When building the JDK on >>> Alpine (really: on a PaX enabled system) the buildjdk needs to have >>> its executables marked as well, but when cross compiling that?s not >>> necessarily needed. >>> * The patch currently bases the decision on whether to mark the >>> executables on whether the target CLIB is ?musl?, where in fact that >>> doesn?t really have anything to do with musl >>> * Not all executables necessarily load and run the JVM, so not all of >>> them necessarily need to be marked >>> * It?s not really the user space that decides whether the PaX >>> relaxation is needed - it?s the kernel. That means that when running >>> in, say, Docker, even if the base image would be Alpine (or some >>> other distribution which has PaX enabled by default), it?s really the >>> configuration of the host system kernel which comes into play. >>> >>> I?m not sure what the right solution is here. Taking suggestions. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://pax.grsecurity.net >>> > From mikael.vidstedt at oracle.com Thu Apr 13 14:05:30 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Apr 2017 07:05:30 -0700 Subject: RFR: Disable PaX mprotect on executables In-Reply-To: <7ae33ac7-b44c-c2ed-e065-51282d2c58d7@oracle.com> References: <7ae33ac7-b44c-c2ed-e065-51282d2c58d7@oracle.com> Message-ID: <6CAD090D-735C-4F79-B94E-9EA0F77B711A@oracle.com> > On Apr 13, 2017, at 1:06 AM, David Holmes wrote: > > On 13/04/2017 5:31 PM, Erik Joelsson wrote: >> On 2017-04-13 07:00, David Holmes wrote: >>> Hi Mikael, >>> >>> On 13/04/2017 9:09 AM, Mikael Vidstedt wrote: >>>> >>>> Alpine by default has PaX [1] enabled. Among other things, PaX tries >>>> to prevent various attack vectors by controlling the ways in which >>>> page protection can be updated/changed. For example, it does not >>>> allow marking previously writable pages as executable. Guess what >>>> hotspot likes to do? >>>> >>>> This change is incomplete, and I could use some help figuring out how >>>> to complete it. >>> >>> In all seriousness I would not do this. I think it is up to the >>> "deployer" of a JRE on such a system to take whatever PaX related >>> steps are needed to allow the binaries to run. I don't think we should >>> be making any such decisions at build time, nor requiring paxctl be >>> available. All we should do is document what is required. >>> >> I think we do have to support this. Alpine is the platform we are being >> asked to support and our bits will be DoA unless this is done. This will > > I look at this from the perspective of a security conscious user. If I have chosen a hardened platform, and I am choosing software I want to run on that platform, then I want to decide how/whether security should be relaxed for a given binary - not some third-party (and especially not the third-party that supplied the software that I don't necessarily trust!). That is definitely a very good point - I?ll have to digest. One of the things we may want to do in either case is add an explicit test during boot to check if a mmap/mprotect call (mimicking the normal operation we do) fails, and if we notice that the test fails we can perhaps recommend the user to look into the PaX settings, and refer to paxctl. > >> get very annoying quickly when trying to test the bits. Unless, of >> course, we only support and test on alpine in containers. Whichever we >> do, it needs to be documented. > > For our own testing I suggest running Alpine with PaX disabled. It is indeed possible to disable PaX globally on the system using some sysctl voodoo (which is how I got started). Cheers, Mikael > > David > ----- > >> You are correct that this has nothing to do with muscl, so I think it >> should be controlled with a specific configure flag (--enable-pax?) and >> it should be default off. We would need to put paxctl in the devkit for >> the affected platform(s) since it's not default installed on our build >> platforms today (or create a separate package with it, perhaps easier). >> In our jib profile configuration we would enable this for the alpine >> linux builds. >> >> Supporting running the build on a PaX enabled system is a different >> issue. If we want to support this, then we could have configure detect >> that PaX is currently active (I assume that's possible) and take the >> necessary precautions to use paxctl on at least the buildjdk, and if not >> cross compiling, also the target jdk. This would be the only case where >> the default value of the flag would be true. >> >> /Erik >> >>> David >>> ----- >>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/ >>>> >>>> >>>> Basically, it all comes down to needing to use a tool - paxctl - to >>>> mark the executables in a way so that the kernel knows to >>>> disable/relax some of the PaX features for the process. The patch >>>> adds support for finding the paxctl tool, and for using the tool (if >>>> found) to mark the excutable. However, here are two of the main >>>> reasons why this patch is incomplete: >>>> >>>> * There are two different JDKs which may or may not need the special >>>> paxctl treatment: buildjdk and target jdk. When building the JDK on >>>> Alpine (really: on a PaX enabled system) the buildjdk needs to have >>>> its executables marked as well, but when cross compiling that?s not >>>> necessarily needed. >>>> * The patch currently bases the decision on whether to mark the >>>> executables on whether the target CLIB is ?musl?, where in fact that >>>> doesn?t really have anything to do with musl >>>> * Not all executables necessarily load and run the JVM, so not all of >>>> them necessarily need to be marked >>>> * It?s not really the user space that decides whether the PaX >>>> relaxation is needed - it?s the kernel. That means that when running >>>> in, say, Docker, even if the base image would be Alpine (or some >>>> other distribution which has PaX enabled by default), it?s really the >>>> configuration of the host system kernel which comes into play. >>>> >>>> I?m not sure what the right solution is here. Taking suggestions. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://pax.grsecurity.net From mikael.vidstedt at oracle.com Thu Apr 13 16:02:47 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Apr 2017 09:02:47 -0700 Subject: RFR: Add musl information to bundle names and -Xinternalversion Message-ID: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> With the introduction of musl - (and specifically linux-amd64) is no longer uniquely identifying the JDK platform and binaries. This change adds ?musl? in a couple of places: top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ The two places are: 1. The bundle file names A typical linux-amd64 bundle today looks something like this: jdk-10-internal+0_linux-x64_bin.tar.gz At least for now, the ?normal?/gnu bundle file names will *not* be changed - only the new ?musl? ones will get the additional ?-musl? component: jdk-10-internal+0_linux-x64-musl_bin.tar.gz 2. The -Xinternalversion version string Much like with the bundle names, the current string looks something like: Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:48:18 by "mikael" with gcc 4.9.2 This patch (only) adds ?-musl? for the musl version of the JVM, and leaves non-musl platforms unchanged. With musl the -Xinternalversion version string looks something like: Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64-musl JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:34:03 by "mikael" with gcc 4.9.2 but without the bold highlighting ;) As I mentioned in the thread [1] for the confstr/libc/libpthread patch I will take another round through the code after I have this in place and make sure everything is handled in a consistent manner. Cheers, Mikael [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html From mikael.vidstedt at oracle.com Thu Apr 13 16:19:03 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Apr 2017 09:19:03 -0700 Subject: RFR: Make Serviceability Agent attach functionality optional Message-ID: The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ Cheers, Mikael From mikael.vidstedt at oracle.com Thu Apr 13 22:04:54 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 13 Apr 2017 22:04:54 +0000 Subject: hg: portola/portola: Make Serviceability Agent attach functionality optional Message-ID: <201704132204.v3DM4seb024621@aojmv0008.oracle.com> Changeset: 7f012cf14d29 Author: mikael Date: 2017-04-13 15:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/7f012cf14d29 Make Serviceability Agent attach functionality optional ! common/autoconf/configure.ac ! common/autoconf/hotspot.m4 ! common/autoconf/spec.gmk.in From mikael.vidstedt at oracle.com Thu Apr 13 22:05:03 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 13 Apr 2017 22:05:03 +0000 Subject: hg: portola/portola/hotspot: Make Serviceability Agent attach functionality optional Message-ID: <201704132205.v3DM54kT024762@aojmv0008.oracle.com> Changeset: 6860d59d26f4 Author: mikael Date: 2017-04-13 15:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/6860d59d26f4 Make Serviceability Agent attach functionality optional ! make/lib/Lib-jdk.hotspot.agent.gmk ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.c ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c From mikael.vidstedt at oracle.com Thu Apr 13 22:31:18 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Apr 2017 15:31:18 -0700 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: References: Message-ID: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> FYI: I messed up the details of the patch. Working on fixing it. Cheers, Mikael > On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: > > > The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. > > musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. > > Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). > > top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Thu Apr 13 23:36:25 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Apr 2017 16:36:25 -0700 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> References: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> Message-ID: <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> Here?s an ugly incremental fix to get things building again: hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/attachfix/webrev.00/hotspot/webrev/ I?m going to file an enhancement to follow up on this to see if it can be cleaned up. Meanwhile, please have a look at the changes - both the ones I send out earlier, and the above fix. Cheers, Mikael > On Apr 13, 2017, at 3:31 PM, Mikael Vidstedt wrote: > > > FYI: I messed up the details of the patch. Working on fixing it. > > Cheers, > Mikael > >> On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: >> >> >> The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. >> >> musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. >> >> Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). >> >> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ >> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ >> >> Cheers, >> Mikael >> > From mikael.vidstedt at oracle.com Thu Apr 13 23:38:57 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 13 Apr 2017 23:38:57 +0000 Subject: hg: portola/portola/hotspot: Fix broken SA attach change Message-ID: <201704132338.v3DNcv4o022861@aojmv0008.oracle.com> Changeset: 2f8708430541 Author: mikael Date: 2017-04-13 16:37 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/2f8708430541 Fix broken SA attach change ! make/lib/Lib-jdk.hotspot.agent.gmk ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.h ! src/jdk.hotspot.agent/linux/native/libsaproc/proc_service.h From mikael.vidstedt at oracle.com Fri Apr 14 00:04:17 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 14 Apr 2017 00:04:17 +0000 Subject: hg: portola/portola/hotspot: Add musl information to bundle names and -Xinternalversion Message-ID: <201704140004.v3E04HsH000282@aojmv0008.oracle.com> Changeset: 6673a37387c0 Author: mikael Date: 2017-04-13 17:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/6673a37387c0 Add musl information to bundle names and -Xinternalversion ! make/lib/CompileJvm.gmk ! src/share/vm/runtime/vm_version.cpp From mikael.vidstedt at oracle.com Fri Apr 14 00:04:38 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 14 Apr 2017 00:04:38 +0000 Subject: hg: portola/portola: Add musl information to bundle names and -Xinternalversion Message-ID: <201704140004.v3E04dAq000372@aojmv0008.oracle.com> Changeset: 86621d720e4e Author: mikael Date: 2017-04-13 17:02 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/86621d720e4e Add musl information to bundle names and -Xinternalversion ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! make/ReleaseFile.gmk From mikael.vidstedt at oracle.com Fri Apr 14 00:45:29 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Apr 2017 17:45:29 -0700 Subject: RFR: Unaligned pointer dereference crash in ClassFileParser In-Reply-To: <5a43c893-5476-5c21-5118-d183cc1cdfa7@oracle.com> References: <2675F2D9-95FD-438B-8B58-A06B5CCD75DB@oracle.com> <5a43c893-5476-5c21-5118-d183cc1cdfa7@oracle.com> Message-ID: <54480D33-498B-4846-AA79-688BE4D34FF3@oracle.com> > On Apr 12, 2017, at 8:18 PM, David Holmes wrote: > > Hi Mikael, > > I really like the cleanup of is_Java_byte_ordering_different to utilize build-time endian information so it can go in shared code. I agree, it?s one of the parts of the patch I like the most ;) > > The rest seems okay in principle - I can't really comment on the template details but the overall approach looks quite reasonable. Thanks! > > Nit: conjoint_swap_maybe -> conjoint_swap_if_needed Fixed. > Nit: where you changed signatures to return void* instead of u2* you need to realign the arguments lists by 2 spaces. Fixed in 2 places (webrev is making it look like it?s wrong in more places than it actually is). Cheers, Mikael > > Thanks, > David > > On 12/04/2017 2:55 PM, Mikael Vidstedt wrote: >> >> This one is interesting, and requires a bit of background. Get yourself a cup of coffee/tea if you haven?t already. I?d actually like to push this this jdk10 as well sometime soon-ish, because it?s an actual/latent bug which may be tickled if our toolchain changes in some way. It?s not actually a musl bug per-se, it just happens to be tickled when compiling for musl. >> >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/portola/copyswapaligned/webrev.00/hotspot/webrev/ >> >> The story goes something like this: >> >> x86 is normally very forgiving when it comes to dereferencing unaligned pointers. Even if the pointer isn?t aligned on the natural size of the element being accessed, the hardware will do the Right Thing(tm) and nobody gets hurt. However, turns out there are exceptions to this. Specifically, SSA2 introduced the movdqa instruction, which is a 128-bit load/store which *does* require that the pointer is 128-bit aligned. >> >> Normally this isn?t a problem, because after all we don?t typically use 128-bit data types in our C/C++ code. However, just because we don?t use any such data types explicitly, there?s nothing preventing the C compiler to do so under the covers. Specifically, the C compiler tends to do loop unrolling and vectorization, which can turn pretty much any data access into vectorized SIMD accesses. >> >> We?ve actually run into a variation on this exact same problem a while back when upgrading to gcc 4.9.2 [1]. That time the problem was in nio/Bits.c, and it was fixed (by me) by moving the copy functionality into hotspot (copy.[ch]pp), making sure the copy logic does the relevant alignment checks etc. >> >> This time the problem is with ClassFileParser. Or more accurately, it?s in the methods ClassFileParser makes use of. Specifically, the problem is with the copy_u2_with_conversion method, used to copy various data from the class file and put it in the ?native? endian order in memory. It, in turn, uses Bytes::get_Java_u2 to read and potentially byte swap a 16-bit entry from the class file. bytes_x86.hpp has this to say about its implementation: >> >> // Efficient reading and writing of unaligned unsigned data in platform-specific byte ordering >> // (no special code is needed since x86 CPUs can access unaligned data) >> >> While that is /almost/ always true for the x86 architecture in itself, the C standard still expects accesses to be aligned, and the C compiler is free to make use of that expectation to, for example, vectorize operations and make use of the movdqa instruction. >> >> So why is this only a problem when using musl? Turns out it sorta isn?t, but bytes_x86.hpp will, in the end, actually use system library functions to do byte swapping. Specifically, on linux_x86 it will come down to bytes_linux_x86.inline.hpp which, on AMD64, uses the system functions/macros swap_u{16,32,64} to do the actual byte swapping. Now here?s the ?funny? & interesting part: >> >> With glibc, the swap_u{16,32,64} methods are implemented using inline assembly - in the end it comes down to a rotate ?rorw? instruction. Since GCC can?t see through the inline assembly, it will not realize that there are loop unrolling/vectorization opportunities, and of specific interest to us: the movdqa instruction will not be used. The code will potentially not be as efficient as it could be, but it will be functional. >> >> With musl, the swap methods are instead implemented as normal macros, shifting bits around to achieve the desired effect. GCC recognizes the bit shifting patterns, will realize that it?s just byte swapping a bunch of values, will vectorize the loop, and *will* make use of the movdqa instruction. Kaboom. >> >> To recap: dereferencing unaligned pointers in C/C++ is a no-no, even in cases where you think it should be okay. >> >> >> That concludes the background. Let?s move over to the suggested fix. There are (at least) two alternatives: >> >> 1. Only fix the specific case of classFileStream.cpp/copy_u2_with_conversion >> 2. Address the larger problem of Bytes providing methods which may not be safe >> >> For better or worse, the webrev I linked to above does the latter - it doesn?t just do the minimal change. I?m happy to revisit that and reduce the scope of the patch if needed. >> >> >> The key changes are in three different areas, the first two of which are needed (in one way or another): >> >> * copy.[ch]pp >> >> Introducing: conjoint_swap_maybe >> >> conjoint_swap_maybe will copy data, and bytes wap it on-the-fly if the specified endianness differs from the native/CPU endianness. It does this by either delegating to conjoint_swap (on endian mismatch), or conjoint_copy (on match). In copy.cpp, the changes all boil down to making the innermost do_conjoint_swap method more flexible so that it can be reused for both cases (straight copy as well as copy+swap). >> >> * classFile{Parser,Stream} >> >> The key (and only absolutely needed) change is in classFileParser.cpp, switching to copying data from the class file using the new conjoint_swap_maybe method, replacing the loop implemented in copy_u2_with_conversion/Bytes::get_Java_u2. >> >> However, in addition to that change, I noticed that there are a lot of u2* passed around in the code, pointers which are not necessarily 16-bit aligned. While there?s nothing wrong with *having* an unaligned pointer in C - as long as it?s not dereferenced everything is peachy - it made me uneasy to see it passed around and used the way it is. Specifically, ClassFileStream::get_u2_buffer() could, to the untrained eye, be a bit misleading. One could accidentally and incorrectly assume that the returned pointer is, in fact, 16-bit aligned and start dereferencing it directly, where in fact there is no such guarantee. Perhaps even use it as an array and attract the wrath of the C compiler. >> >> Changing to void* may or may not be the right thing to do here. In a way I?d actually like to ?carry? the type information, but in some way still prevent the pointer from being directly dereferenced. Taking suggestions. >> >> >> * bytes_x86.hpp >> >> Note: I believe that given the above changes, this one isn?t absolutely necessary. This is addressing the wider concern that other parts of hotspot may use the same primitives in much the same (potentially broken) way, and in particular the fact that the get/put primitives aren?t checking whether the pointer argument is aligned before they dereference it. It may well be that a simple assert or two would do the trick here. That said: >> >> It turns out that the various platforms all have their own unique ways of implementing bytes.hpp, duplicating some logic which could/should be platform independent. I tried to clean up and unify it all a bit while at it by introducing an Endian helper class in bytes.hpp. The primitives for accessing data in memory now check for alignment and either perform the raw memory access (when the pointer is aligned), or does a memcpy (if unaligned). There?s some template ?magic? in there avoid duplicating code, but hopefully the magic is relatively straightforward. >> >> >> >> Appreciate any and all comments and feedback. As mentioned, I think this is worth pushing to jdk10 as well in some not-all-too-distant future. >> >> Cheers, >> Mikael >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8141491 >> From mikael.vidstedt at oracle.com Fri Apr 14 00:47:24 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 14 Apr 2017 00:47:24 +0000 Subject: hg: portola/portola/hotspot: Unaligned pointer dereference crash in ClassFileParser Message-ID: <201704140047.v3E0lPpv011398@aojmv0008.oracle.com> Changeset: b4aa1fbf0d74 Author: mikael Date: 2017-04-13 17:45 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/b4aa1fbf0d74 Unaligned pointer dereference crash in ClassFileParser ! src/cpu/aarch64/vm/bytes_aarch64.hpp ! src/cpu/arm/vm/bytes_arm.hpp ! src/cpu/ppc/vm/bytes_ppc.hpp ! src/cpu/s390/vm/bytes_s390.hpp ! src/cpu/sparc/vm/bytes_sparc.hpp ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/bytes.hpp ! src/share/vm/utilities/copy.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.hpp From mikael.vidstedt at oracle.com Fri Apr 14 00:53:56 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 14 Apr 2017 00:53:56 +0000 Subject: hg: portola/portola: Regenerated autoconf script (using autogen.sh) Message-ID: <201704140053.v3E0rudn013792@aojmv0008.oracle.com> Changeset: 3edf61ee2563 Author: mikael Date: 2017-04-13 17:51 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/3edf61ee2563 Regenerated autoconf script (using autogen.sh) ! common/autoconf/generated-configure.sh From jini.george at oracle.com Fri Apr 14 17:26:54 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 14 Apr 2017 22:56:54 +0530 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> References: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> Message-ID: <4adac24e-254d-5907-dcec-e6cc5be14fac@oracle.com> Looks ok to me, a couple of nits though: * in Lib-jdk.hotspot.agent.gmk, a space would be needed after the comma at lines 60 and 102: ifeq ($(INCLUDE_SA_ATTACH),true) * In proc_service.h, we have the following lines: 76 // new libthread_db of NPTL seem to require this symbol 77 ps_err_e ps_get_thread_area(); So might make sense to have this too under #ifdef INCLUDE_SA_ATTACH * Looks like the inclusion of thread_db.h and the corresponding functions will have to be guarded with INCLUDE_SA_ATTACH in libproc_impl.c too. Thanks, Jini. On 4/14/2017 5:06 AM, Mikael Vidstedt wrote: > Here?s an ugly incremental fix to get things building again: > > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/attachfix/webrev.00/hotspot/webrev/ > > I?m going to file an enhancement to follow up on this to see if it can be cleaned up. Meanwhile, please have a look at the changes - both the ones I send out earlier, and the above fix. > > Cheers, > Mikael > >> On Apr 13, 2017, at 3:31 PM, Mikael Vidstedt wrote: >> >> >> FYI: I messed up the details of the patch. Working on fixing it. >> >> Cheers, >> Mikael >> >>> On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: >>> >>> >>> The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. >>> >>> musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. >>> >>> Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). >>> >>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ >>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ >>> >>> Cheers, >>> Mikael >>> From erik.joelsson at oracle.com Tue Apr 18 10:18:06 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Apr 2017 12:18:06 +0200 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> Message-ID: It looks to me like your code in platform.m4 will indeed change the platform name on gnu linux (and all other platforms) to add a trailing dash '-' for the bundle platform. I also fail to see where the dash before musl is added in the version string? /Erik On 2017-04-13 18:02, Mikael Vidstedt wrote: > With the introduction of musl - (and specifically linux-amd64) is no longer uniquely identifying the JDK platform and binaries. > > This change adds ?musl? in a couple of places: > > top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ > > > The two places are: > > 1. The bundle file names > > A typical linux-amd64 bundle today looks something like this: > > jdk-10-internal+0_linux-x64_bin.tar.gz > > At least for now, the ?normal?/gnu bundle file names will *not* be changed - only the new ?musl? ones will get the additional ?-musl? component: > > jdk-10-internal+0_linux-x64-musl_bin.tar.gz > > > 2. The -Xinternalversion version string > > Much like with the bundle names, the current string looks something like: > > Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:48:18 by "mikael" with gcc 4.9.2 > > This patch (only) adds ?-musl? for the musl version of the JVM, and leaves non-musl platforms unchanged. With musl the -Xinternalversion version string looks something like: > > Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64-musl JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:34:03 by "mikael" with gcc 4.9.2 > > but without the bold highlighting ;) > > > As I mentioned in the thread [1] for the confstr/libc/libpthread patch I will take another round through the code after I have this in place and make sure everything is handled in a consistent manner. > > Cheers, > Mikael > > [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html > From erik.joelsson at oracle.com Tue Apr 18 11:12:01 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Apr 2017 13:12:01 +0200 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> References: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> Message-ID: I would prefer this construct in Lib-jdk.hotspot.agent.gmk to avoid duplication: SA_LIBS := $(LIBDL) ifeq ($(INCLUDE_SA_ATTACH), true) SA_LIBS += -lthread_db endif I agree with using space after comma in the makefiles, we try to do that when possible. /Erik On 2017-04-14 01:36, Mikael Vidstedt wrote: > Here?s an ugly incremental fix to get things building again: > > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/attachfix/webrev.00/hotspot/webrev/ > > I?m going to file an enhancement to follow up on this to see if it can be cleaned up. Meanwhile, please have a look at the changes - both the ones I send out earlier, and the above fix. > > Cheers, > Mikael > >> On Apr 13, 2017, at 3:31 PM, Mikael Vidstedt wrote: >> >> >> FYI: I messed up the details of the patch. Working on fixing it. >> >> Cheers, >> Mikael >> >>> On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: >>> >>> >>> The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. >>> >>> musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. >>> >>> Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). >>> >>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ >>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ >>> >>> Cheers, >>> Mikael >>> From mikael.vidstedt at oracle.com Tue Apr 18 20:56:16 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 18 Apr 2017 13:56:16 -0700 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> Message-ID: <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> I linked to the wrong webrevs, sorry about that. Please have a look at these ones instead (which reflect the changes I actually pushed): top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/ Cheers, Mikael > On Apr 18, 2017, at 3:18 AM, Erik Joelsson wrote: > > It looks to me like your code in platform.m4 will indeed change the platform name on gnu linux (and all other platforms) to add a trailing dash '-' for the bundle platform. > > I also fail to see where the dash before musl is added in the version string? > > /Erik > > On 2017-04-13 18:02, Mikael Vidstedt wrote: >> With the introduction of musl - (and specifically linux-amd64) is no longer uniquely identifying the JDK platform and binaries. >> >> This change adds ?musl? in a couple of places: >> >> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ >> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ >> >> >> The two places are: >> >> 1. The bundle file names >> >> A typical linux-amd64 bundle today looks something like this: >> >> jdk-10-internal+0_linux-x64_bin.tar.gz >> >> At least for now, the ?normal?/gnu bundle file names will *not* be changed - only the new ?musl? ones will get the additional ?-musl? component: >> >> jdk-10-internal+0_linux-x64-musl_bin.tar.gz >> >> >> 2. The -Xinternalversion version string >> >> Much like with the bundle names, the current string looks something like: >> >> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:48:18 by "mikael" with gcc 4.9.2 >> >> This patch (only) adds ?-musl? for the musl version of the JVM, and leaves non-musl platforms unchanged. With musl the -Xinternalversion version string looks something like: >> >> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64-musl JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:34:03 by "mikael" with gcc 4.9.2 >> >> but without the bold highlighting ;) >> >> >> As I mentioned in the thread [1] for the confstr/libc/libpthread patch I will take another round through the code after I have this in place and make sure everything is handled in a consistent manner. >> >> Cheers, >> Mikael >> >> [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html >> > From mikael.vidstedt at oracle.com Tue Apr 18 21:56:43 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 18 Apr 2017 21:56:43 +0000 Subject: hg: portola/portola/hotspot: Clean up of Lib-jdk.hotspot.agent.gmk Message-ID: <201704182156.v3ILuhN8023051@aojmv0008.oracle.com> Changeset: efaadfa1c887 Author: mikael Date: 2017-04-18 14:54 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/efaadfa1c887 Clean up of Lib-jdk.hotspot.agent.gmk ! make/lib/Lib-jdk.hotspot.agent.gmk From mikael.vidstedt at oracle.com Tue Apr 18 21:55:59 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 18 Apr 2017 14:55:59 -0700 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: <4adac24e-254d-5907-dcec-e6cc5be14fac@oracle.com> References: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> <4adac24e-254d-5907-dcec-e6cc5be14fac@oracle.com> Message-ID: <5178449E-909B-4082-BFB3-7BCAE4FAD2D6@oracle.com> > On Apr 14, 2017, at 10:26 AM, Jini George wrote: > > Looks ok to me, a couple of nits though: > > * in Lib-jdk.hotspot.agent.gmk, a space would be needed after the comma at lines 60 and 102: > > ifeq ($(INCLUDE_SA_ATTACH),true) Fixed. > * In proc_service.h, we have the following lines: > > 76 // new libthread_db of NPTL seem to require this symbol > 77 ps_err_e ps_get_thread_area(); > > So might make sense to have this too under #ifdef INCLUDE_SA_ATTACH As a matter of fact, ps_get_thread_area() seems to be dead code (AFAICT it?s not used anywhere) so the right course of action is probably just to remove it? Perhaps something we can do in mainline/jdk10? > * Looks like the inclusion of thread_db.h and the corresponding functions will have to be guarded with INCLUDE_SA_ATTACH in libproc_impl.c too. I?m assuming that you?re asking for the guards I added in the first, incomplete change I made: http://hg.openjdk.java.net/portola/portola/hotspot/rev/6860d59d26f4 Cheers, Mikael > > > Thanks, > Jini. > > On 4/14/2017 5:06 AM, Mikael Vidstedt wrote: >> Here?s an ugly incremental fix to get things building again: >> >> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/attachfix/webrev.00/hotspot/webrev/ >> >> I?m going to file an enhancement to follow up on this to see if it can be cleaned up. Meanwhile, please have a look at the changes - both the ones I send out earlier, and the above fix. >> >> Cheers, >> Mikael >> >>> On Apr 13, 2017, at 3:31 PM, Mikael Vidstedt wrote: >>> >>> >>> FYI: I messed up the details of the patch. Working on fixing it. >>> >>> Cheers, >>> Mikael >>> >>>> On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: >>>> >>>> >>>> The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. >>>> >>>> musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. >>>> >>>> Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). >>>> >>>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ >>>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ >>>> >>>> Cheers, >>>> Mikael >>>> > From mikael.vidstedt at oracle.com Tue Apr 18 21:56:38 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 18 Apr 2017 14:56:38 -0700 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: References: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> Message-ID: <8A37B9FC-9DD9-44F4-BDE7-315D428BF6B0@oracle.com> > On Apr 18, 2017, at 4:12 AM, Erik Joelsson wrote: > > I would prefer this construct in Lib-jdk.hotspot.agent.gmk to avoid duplication: > > SA_LIBS := $(LIBDL) > ifeq ($(INCLUDE_SA_ATTACH), true) > SA_LIBS += -lthread_db > endif I meant to do that before pushing, thanks for the catch. Fixed. > I agree with using space after comma in the makefiles, we try to do that when possible. Fixed. Cheers, Mikael > > /Erik > > On 2017-04-14 01:36, Mikael Vidstedt wrote: >> Here?s an ugly incremental fix to get things building again: >> >> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/attachfix/webrev.00/hotspot/webrev/ >> >> I?m going to file an enhancement to follow up on this to see if it can be cleaned up. Meanwhile, please have a look at the changes - both the ones I send out earlier, and the above fix. >> >> Cheers, >> Mikael >> >>> On Apr 13, 2017, at 3:31 PM, Mikael Vidstedt wrote: >>> >>> >>> FYI: I messed up the details of the patch. Working on fixing it. >>> >>> Cheers, >>> Mikael >>> >>>> On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: >>>> >>>> >>>> The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. >>>> >>>> musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. >>>> >>>> Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). >>>> >>>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ >>>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ >>>> >>>> Cheers, >>>> Mikael >>>> > From david.holmes at oracle.com Tue Apr 18 22:13:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Apr 2017 08:13:08 +1000 Subject: RFR: Make Serviceability Agent attach functionality optional In-Reply-To: <5178449E-909B-4082-BFB3-7BCAE4FAD2D6@oracle.com> References: <1C7CA161-A8FB-465D-B415-19078D299A3A@oracle.com> <83D92AB5-F144-4EFC-8F5E-2592F5503B1D@oracle.com> <4adac24e-254d-5907-dcec-e6cc5be14fac@oracle.com> <5178449E-909B-4082-BFB3-7BCAE4FAD2D6@oracle.com> Message-ID: <89cc5d2f-7f19-b456-92cc-c7e42d90663e@oracle.com> On 19/04/2017 7:55 AM, Mikael Vidstedt wrote: > >> On Apr 14, 2017, at 10:26 AM, Jini George wrote: >> >> Looks ok to me, a couple of nits though: >> >> * in Lib-jdk.hotspot.agent.gmk, a space would be needed after the comma at lines 60 and 102: >> >> ifeq ($(INCLUDE_SA_ATTACH),true) > > Fixed. > >> * In proc_service.h, we have the following lines: >> >> 76 // new libthread_db of NPTL seem to require this symbol >> 77 ps_err_e ps_get_thread_area(); >> >> So might make sense to have this too under #ifdef INCLUDE_SA_ATTACH > > As a matter of fact, ps_get_thread_area() seems to be dead code (AFAICT it?s not used anywhere) so the right course of action is probably just to remove it? Perhaps something we can do in mainline/jdk10? Sounds to me like they were getting a link error if that symbol did not exist. David ----- >> * Looks like the inclusion of thread_db.h and the corresponding functions will have to be guarded with INCLUDE_SA_ATTACH in libproc_impl.c too. > > I?m assuming that you?re asking for the guards I added in the first, incomplete change I made: > > http://hg.openjdk.java.net/portola/portola/hotspot/rev/6860d59d26f4 > > Cheers, > Mikael > >> >> >> Thanks, >> Jini. >> >> On 4/14/2017 5:06 AM, Mikael Vidstedt wrote: >>> Here?s an ugly incremental fix to get things building again: >>> >>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/attachfix/webrev.00/hotspot/webrev/ >>> >>> I?m going to file an enhancement to follow up on this to see if it can be cleaned up. Meanwhile, please have a look at the changes - both the ones I send out earlier, and the above fix. >>> >>> Cheers, >>> Mikael >>> >>>> On Apr 13, 2017, at 3:31 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> FYI: I messed up the details of the patch. Working on fixing it. >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> On Apr 13, 2017, at 9:19 AM, Mikael Vidstedt wrote: >>>>> >>>>> >>>>> The Serviceability Agent (aka. SA) has functionality to attach to running processes forcefully/without the cooperation of the VM, allowing ?live? debugging even when the processes is stuck. On linux the implementation relies on the functionality provided by the thread_db.h header file. >>>>> >>>>> musl doesn?t support thread_db.h (or any other thread debugging library for that sake). This patch makes the inclusion of the attach/live debugging support optional, and only includes it if the thread_db.h header file is available. >>>>> >>>>> Note that the core debugging functionality still works without the attach/live debugging functionality in the SA (at least in theory, I haven?t taken core debugging for a spin yet). >>>>> >>>>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/webrev/ >>>>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/sathreaddb/webrev.00/hotspot/webrev/ >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >> > From erik.joelsson at oracle.com Wed Apr 19 09:38:55 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Apr 2017 11:38:55 +0200 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> Message-ID: <2e771828-b1e0-0260-4f4f-a19af674fd01@oracle.com> That looks much better. :) /Erik On 2017-04-18 22:56, Mikael Vidstedt wrote: > > I linked to the wrong webrevs, sorry about that. Please have a look at > these ones instead (which reflect the changes I actually pushed): > > top: > http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/ > > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/ > > > Cheers, > Mikael > >> On Apr 18, 2017, at 3:18 AM, Erik Joelsson > > wrote: >> >> It looks to me like your code in platform.m4 will indeed change the >> platform name on gnu linux (and all other platforms) to add a >> trailing dash '-' for the bundle platform. >> >> I also fail to see where the dash before musl is added in the version >> string? >> >> /Erik >> >> On 2017-04-13 18:02, Mikael Vidstedt wrote: >>> With the introduction of musl - (and specifically >>> linux-amd64) is no longer uniquely identifying the JDK platform and >>> binaries. >>> >>> This change adds ?musl? in a couple of places: >>> >>> top: >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ >>> >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ >>> >>> >>> >>> The two places are: >>> >>> 1. The bundle file names >>> >>> A typical linux-amd64 bundle today looks something like this: >>> >>> jdk-10-internal+0_linux-x64_bin.tar.gz >>> >>> At least for now, the ?normal?/gnu bundle file names will *not* be >>> changed - only the new ?musl? ones will get the additional ?-musl? >>> component: >>> >>> jdk-10-internal+0_linux-x64-musl_bin.tar.gz >>> >>> >>> 2. The -Xinternalversion version string >>> >>> Much like with the bundle names, the current string looks something >>> like: >>> >>> Java HotSpot(TM) 64-Bit Server VM >>> (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE >>> (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 >>> 2017 08:48:18 by "mikael" with gcc 4.9.2 >>> >>> This patch (only) adds ?-musl? for the musl version of the JVM, and >>> leaves non-musl platforms unchanged. With musl the -Xinternalversion >>> version string looks something like: >>> >>> Java HotSpot(TM) 64-Bit Server VM >>> (10-internal+0-2017-04-10-172118.mikael.portola) for >>> linux-amd64-musl JRE >>> (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 >>> 2017 08:34:03 by "mikael" with gcc 4.9.2 >>> >>> but without the bold highlighting ;) >>> >>> >>> As I mentioned in the thread [1] for the confstr/libc/libpthread >>> patch I will take another round through the code after I have this >>> in place and make sure everything is handled in a consistent manner. >>> >>> Cheers, >>> Mikael >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html >>> >> > From timo.teras at iki.fi Fri Apr 21 18:41:59 2017 From: timo.teras at iki.fi (Timo Teras) Date: Fri, 21 Apr 2017 21:41:59 +0300 Subject: Alpine patches Message-ID: <20170421214159.224dcf9a@vostro> Hi, Very good that you are working on official Alpine support. Please take a look at the patches we carry in Alpine to build icedtea version of openjdk: https://git.alpinelinux.org/cgit/aports/tree/community/openjdk8 Perhaps some of them can be applied as is. If you have any questions, feel free to ask me or alpine-devel at lists.alpinelinux.org. Thanks, Timo From dalibor.topic at oracle.com Mon Apr 24 13:00:02 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 24 Apr 2017 15:00:02 +0200 Subject: Alpine patches In-Reply-To: <20170421214159.224dcf9a@vostro> References: <20170421214159.224dcf9a@vostro> Message-ID: <218bcf4e-6ee5-d81a-ccaf-c8c27ef717f4@oracle.com> Hi Timo, unfortunately, we can't take patches from third party sites. They need to be submitted by their authors to OpenJDK. Please see http://openjdk.java.net/contribute/ for details on contributing. cheers, dalibor topic On 21.04.2017 20:41, Timo Teras wrote: > Hi, > > Very good that you are working on official Alpine support. > > Please take a look at the patches we carry in Alpine to build icedtea > version of openjdk: > > https://git.alpinelinux.org/cgit/aports/tree/community/openjdk8 > > Perhaps some of them can be applied as is. If you have any questions, > feel free to ask me or alpine-devel at lists.alpinelinux.org. > > Thanks, > Timo > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From josh at grahamis.com Tue Apr 25 21:35:16 2017 From: josh at grahamis.com (Josh Graham) Date: Wed, 26 Apr 2017 07:35:16 +1000 Subject: Bootstrap build of Portola on Alpine Message-ID: G'day, I've documented what I've done so far to build Portola on an existing Alpine 3.3 with an glibc-based JDK (Zulu, as it happens) at: https://gist.github.com/delitescere/d80c6782cb8d1b6f987dbcb9488f58ca I'll work out what the quoting bug is so the whole thing can be scripted. I'm also on the edge of getting a built JDK but have library load issues at what I'm presuming is verification steps at the end of the make (no time to diagnose yet). There is a comment on that gist describing what I've found so far. Probably something very simple I've overlooked. I'll also work out what packages can be omitted, but it's fairly lean for simply getting a bootstrap build. Azul's Zulu JDK is TCK approved and they have been very generous in supplying me an embedded cp3 version for my JRE image. The reason I'm keen on Portola is I can get that image even smaller without glibc. I understand if you don't want to use untrusted Docker images. The Dockerfile (and that of its base image) are open source, so you can recreate as needed. More soon, Josh From david.holmes at oracle.com Tue Apr 25 23:14:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Apr 2017 09:14:00 +1000 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> Message-ID: <7a202b7b-c2e2-0016-2cd7-4e4fb1631bcb@oracle.com> Hi Mikael, One nit. In make/ReleaseFile.gmk you unconditionally add an entry for "CLIB" but unless on musl that will be an empty string. Seems to me either we always have a defined value for CLIB or else we only conditionally add it to the release info file. Cheers, David On 19/04/2017 6:56 AM, Mikael Vidstedt wrote: > > I linked to the wrong webrevs, sorry about that. Please have a look at these ones instead (which reflect the changes I actually pushed): > > top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/ > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/ > > Cheers, > Mikael > >> On Apr 18, 2017, at 3:18 AM, Erik Joelsson wrote: >> >> It looks to me like your code in platform.m4 will indeed change the platform name on gnu linux (and all other platforms) to add a trailing dash '-' for the bundle platform. >> >> I also fail to see where the dash before musl is added in the version string? >> >> /Erik >> >> On 2017-04-13 18:02, Mikael Vidstedt wrote: >>> With the introduction of musl - (and specifically linux-amd64) is no longer uniquely identifying the JDK platform and binaries. >>> >>> This change adds ?musl? in a couple of places: >>> >>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ >>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ >>> >>> >>> The two places are: >>> >>> 1. The bundle file names >>> >>> A typical linux-amd64 bundle today looks something like this: >>> >>> jdk-10-internal+0_linux-x64_bin.tar.gz >>> >>> At least for now, the ?normal?/gnu bundle file names will *not* be changed - only the new ?musl? ones will get the additional ?-musl? component: >>> >>> jdk-10-internal+0_linux-x64-musl_bin.tar.gz >>> >>> >>> 2. The -Xinternalversion version string >>> >>> Much like with the bundle names, the current string looks something like: >>> >>> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:48:18 by "mikael" with gcc 4.9.2 >>> >>> This patch (only) adds ?-musl? for the musl version of the JVM, and leaves non-musl platforms unchanged. With musl the -Xinternalversion version string looks something like: >>> >>> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64-musl JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:34:03 by "mikael" with gcc 4.9.2 >>> >>> but without the bold highlighting ;) >>> >>> >>> As I mentioned in the thread [1] for the confstr/libc/libpthread patch I will take another round through the code after I have this in place and make sure everything is handled in a consistent manner. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html >>> >> > From mikael.vidstedt at oracle.com Wed Apr 26 20:56:46 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 26 Apr 2017 13:56:46 -0700 Subject: Bootstrap build of Portola on Alpine In-Reply-To: References: Message-ID: > On Apr 25, 2017, at 2:35 PM, Josh Graham wrote: > > G'day, > > I've documented what I've done so far to build Portola on an existing > Alpine 3.3 with an glibc-based JDK (Zulu, as it happens) at: > > https://gist.github.com/delitescere/d80c6782cb8d1b6f987dbcb9488f58ca Thank you very much for taking this for a spin. Really appreciate the feedback - keep it coming! > I'll work out what the quoting bug is so the whole thing can be scripted. I *think* (but see below) that?s same problem I "fixed? by explicitly installing sed or grep or something.. From your package list it looks like you do install grep, but you still run into the problem? Does installing sed help? Out of curiosity, why did you have to do the poll.h softlink workaround? I was naively hoping I had fixed all of the incorrect includes, but maybe I missed something? > I'm also on the edge of getting a built JDK but have library load issues at > what I'm presuming is verification steps at the end of the make (no time to > diagnose yet). There is a comment on that gist describing what I've found > so far. Probably something very simple I've overlooked. I believe this is the missing magic: bash ./configure --host=x86_64-unknown-linux-musl --build=x86_64-unknown-linux-musl Specifically, the problem you?re running into is this guy: http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000047.html Basically you need to help the JDK build system/code understand that you?re building the musl version, because the library path workaround only kicks in with the musl build. I started looking into if/how we can automatically detect that, but for now you need to give it some manual CPR using ?host and ?build. > I'll also work out what packages can be omitted, but it's fairly lean for > simply getting a bootstrap build. Azul's Zulu JDK is TCK approved and they > have been very generous in supplying me an embedded cp3 version for my JRE > image. The reason I'm keen on Portola is I can get that image even smaller > without glibc. I understand if you don't want to use untrusted Docker > images. The Dockerfile (and that of its base image) are open source, so you > can recreate as needed. That package list is almost the same as the one I ended up with: alsa-lib-dev bash cups-dev file freetype-dev g++ grep libx11-dev libxext-dev libxrender-dev libxt-dev libxtst-dev linux-headers make mercurial tar zip Funnily enough I realize that ?sed? isn?t in my list here, and it seems to be working anyway.. I guess I need to go back and have a look at that at some point. > More soon, Looking forward to it! Cheers, Mikael From mikael.vidstedt at oracle.com Wed Apr 26 22:39:42 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 26 Apr 2017 15:39:42 -0700 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: <7a202b7b-c2e2-0016-2cd7-4e4fb1631bcb@oracle.com> References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> <7a202b7b-c2e2-0016-2cd7-4e4fb1631bcb@oracle.com> Message-ID: Actually not, but I can see how these changes are confusing enough to make it seem like that?s the case. The key here is the difference between OPENJDK_TARGET_CLIB and OPENJDK_TARGET_CLIB_BUNDLE. The former is what is baked into the release file, and it always has a value (either ?musl?, ?gnu?, or ?default?). The latter is what is used to form the name of the bundle files (the .tar.gz ones), and that suffix string is either ?-musl?, or empty. Does that make sense? Cheers, Mikael > On Apr 25, 2017, at 4:14 PM, David Holmes wrote: > > Hi Mikael, > > One nit. In make/ReleaseFile.gmk you unconditionally add an entry for "CLIB" but unless on musl that will be an empty string. Seems to me either we always have a defined value for CLIB or else we only conditionally add it to the release info file. > > Cheers, > David > > On 19/04/2017 6:56 AM, Mikael Vidstedt wrote: >> >> I linked to the wrong webrevs, sorry about that. Please have a look at these ones instead (which reflect the changes I actually pushed): >> >> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/ >> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/ >> >> Cheers, >> Mikael >> >>> On Apr 18, 2017, at 3:18 AM, Erik Joelsson wrote: >>> >>> It looks to me like your code in platform.m4 will indeed change the platform name on gnu linux (and all other platforms) to add a trailing dash '-' for the bundle platform. >>> >>> I also fail to see where the dash before musl is added in the version string? >>> >>> /Erik >>> >>> On 2017-04-13 18:02, Mikael Vidstedt wrote: >>>> With the introduction of musl - (and specifically linux-amd64) is no longer uniquely identifying the JDK platform and binaries. >>>> >>>> This change adds ?musl? in a couple of places: >>>> >>>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ >>>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ >>>> >>>> >>>> The two places are: >>>> >>>> 1. The bundle file names >>>> >>>> A typical linux-amd64 bundle today looks something like this: >>>> >>>> jdk-10-internal+0_linux-x64_bin.tar.gz >>>> >>>> At least for now, the ?normal?/gnu bundle file names will *not* be changed - only the new ?musl? ones will get the additional ?-musl? component: >>>> >>>> jdk-10-internal+0_linux-x64-musl_bin.tar.gz >>>> >>>> >>>> 2. The -Xinternalversion version string >>>> >>>> Much like with the bundle names, the current string looks something like: >>>> >>>> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:48:18 by "mikael" with gcc 4.9.2 >>>> >>>> This patch (only) adds ?-musl? for the musl version of the JVM, and leaves non-musl platforms unchanged. With musl the -Xinternalversion version string looks something like: >>>> >>>> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64-musl JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:34:03 by "mikael" with gcc 4.9.2 >>>> >>>> but without the bold highlighting ;) >>>> >>>> >>>> As I mentioned in the thread [1] for the confstr/libc/libpthread patch I will take another round through the code after I have this in place and make sure everything is handled in a consistent manner. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html >>>> >>> >> From mikael.vidstedt at oracle.com Wed Apr 26 22:54:06 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 26 Apr 2017 15:54:06 -0700 Subject: RFR: Change newly introduced CLIB variable names to LIBC Message-ID: Alan asked why I chose to use ?CLIB? for the various variable names/defines I introduced in autoconf/make/code/release file, rather than the much more reasonable ?LIBC?. He is, of course, totally right, so this change changes all the occurrences from CLIB to use LIBC instead: top: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/hotspot/webrev/ jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/jdk/webrev/ Please have a look and verify the sanity of the changes! Cheers, Mikael From david.holmes at oracle.com Thu Apr 27 00:35:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Apr 2017 10:35:39 +1000 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> <7a202b7b-c2e2-0016-2cd7-4e4fb1631bcb@oracle.com> Message-ID: <81e3cd6f-d8f2-364e-9168-12bd61cc3982@oracle.com> On 27/04/2017 8:39 AM, Mikael Vidstedt wrote: > > Actually not, but I can see how these changes are confusing enough to make it seem like that?s the case. The key here is the difference between OPENJDK_TARGET_CLIB and OPENJDK_TARGET_CLIB_BUNDLE. The former is what is baked into the release file, and it always has a value (either ?musl?, ?gnu?, or ?default?). The latter is what is used to form the name of the bundle files (the .tar.gz ones), and that suffix string is either ?-musl?, or empty. > > Does that make sense? I don't see where OPENJDK_TARGET_CLIB gets any value set ?? David > Cheers, > Mikael > >> On Apr 25, 2017, at 4:14 PM, David Holmes wrote: >> >> Hi Mikael, >> >> One nit. In make/ReleaseFile.gmk you unconditionally add an entry for "CLIB" but unless on musl that will be an empty string. Seems to me either we always have a defined value for CLIB or else we only conditionally add it to the release info file. >> >> Cheers, >> David >> >> On 19/04/2017 6:56 AM, Mikael Vidstedt wrote: >>> >>> I linked to the wrong webrevs, sorry about that. Please have a look at these ones instead (which reflect the changes I actually pushed): >>> >>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/ >>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/ >>> >>> Cheers, >>> Mikael >>> >>>> On Apr 18, 2017, at 3:18 AM, Erik Joelsson wrote: >>>> >>>> It looks to me like your code in platform.m4 will indeed change the platform name on gnu linux (and all other platforms) to add a trailing dash '-' for the bundle platform. >>>> >>>> I also fail to see where the dash before musl is added in the version string? >>>> >>>> /Erik >>>> >>>> On 2017-04-13 18:02, Mikael Vidstedt wrote: >>>>> With the introduction of musl - (and specifically linux-amd64) is no longer uniquely identifying the JDK platform and binaries. >>>>> >>>>> This change adds ?musl? in a couple of places: >>>>> >>>>> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ >>>>> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> The two places are: >>>>> >>>>> 1. The bundle file names >>>>> >>>>> A typical linux-amd64 bundle today looks something like this: >>>>> >>>>> jdk-10-internal+0_linux-x64_bin.tar.gz >>>>> >>>>> At least for now, the ?normal?/gnu bundle file names will *not* be changed - only the new ?musl? ones will get the additional ?-musl? component: >>>>> >>>>> jdk-10-internal+0_linux-x64-musl_bin.tar.gz >>>>> >>>>> >>>>> 2. The -Xinternalversion version string >>>>> >>>>> Much like with the bundle names, the current string looks something like: >>>>> >>>>> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:48:18 by "mikael" with gcc 4.9.2 >>>>> >>>>> This patch (only) adds ?-musl? for the musl version of the JVM, and leaves non-musl platforms unchanged. With musl the -Xinternalversion version string looks something like: >>>>> >>>>> Java HotSpot(TM) 64-Bit Server VM (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64-musl JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 2017 08:34:03 by "mikael" with gcc 4.9.2 >>>>> >>>>> but without the bold highlighting ;) >>>>> >>>>> >>>>> As I mentioned in the thread [1] for the confstr/libc/libpthread patch I will take another round through the code after I have this in place and make sure everything is handled in a consistent manner. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html >>>>> >>>> >>> > From david.holmes at oracle.com Thu Apr 27 00:39:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Apr 2017 10:39:10 +1000 Subject: RFR: Change newly introduced CLIB variable names to LIBC In-Reply-To: References: Message-ID: You made a mistake in common/autoconf/buildjdk-spec.gmk.in -OPENJDK_TARGET_CLIB := @OPENJDK_BUILD_CLIB@ +OPENJDK_TARGET_LIB := @OPENJDK_BUILD_LIBC@ Mising 'C' David On 27/04/2017 8:54 AM, Mikael Vidstedt wrote: > > Alan asked why I chose to use ?CLIB? for the various variable names/defines I introduced in autoconf/make/code/release file, rather than the much more reasonable ?LIBC?. He is, of course, totally right, so this change changes all the occurrences from CLIB to use LIBC instead: > > top: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/webrev/ > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/hotspot/webrev/ > jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/jdk/webrev/ > > Please have a look and verify the sanity of the changes! > > Cheers, > Mikael > From david.holmes at oracle.com Thu Apr 27 00:40:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Apr 2017 10:40:49 +1000 Subject: RFR: Add musl information to bundle names and -Xinternalversion In-Reply-To: <81e3cd6f-d8f2-364e-9168-12bd61cc3982@oracle.com> References: <4FC8B8A3-8218-4DC7-95C7-2E9A99029274@oracle.com> <746381F8-9E09-4A73-92C5-BD7167F15BB9@oracle.com> <7a202b7b-c2e2-0016-2cd7-4e4fb1631bcb@oracle.com> <81e3cd6f-d8f2-364e-9168-12bd61cc3982@oracle.com> Message-ID: <56fa1fc3-c696-eda6-7984-8469f6008c89@oracle.com> On 27/04/2017 10:35 AM, David Holmes wrote: > On 27/04/2017 8:39 AM, Mikael Vidstedt wrote: >> >> Actually not, but I can see how these changes are confusing enough to >> make it seem like that?s the case. The key here is the difference >> between OPENJDK_TARGET_CLIB and OPENJDK_TARGET_CLIB_BUNDLE. The former >> is what is baked into the release file, and it always has a value >> (either ?musl?, ?gnu?, or ?default?). The latter is what is used to >> form the name of the bundle files (the .tar.gz ones), and that suffix >> string is either ?-musl?, or empty. >> >> Does that make sense? > > I don't see where OPENJDK_TARGET_CLIB gets any value set ?? Never mind - earlier webrev. Sorry. David > David > > > >> Cheers, >> Mikael >> >>> On Apr 25, 2017, at 4:14 PM, David Holmes >>> wrote: >>> >>> Hi Mikael, >>> >>> One nit. In make/ReleaseFile.gmk you unconditionally add an entry for >>> "CLIB" but unless on musl that will be an empty string. Seems to me >>> either we always have a defined value for CLIB or else we only >>> conditionally add it to the release info file. >>> >>> Cheers, >>> David >>> >>> On 19/04/2017 6:56 AM, Mikael Vidstedt wrote: >>>> >>>> I linked to the wrong webrevs, sorry about that. Please have a look >>>> at these ones instead (which reflect the changes I actually pushed): >>>> >>>> top: >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/ >>>> >>>> >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/ >>>> >>>> >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> On Apr 18, 2017, at 3:18 AM, Erik Joelsson >>>>> wrote: >>>>> >>>>> It looks to me like your code in platform.m4 will indeed change the >>>>> platform name on gnu linux (and all other platforms) to add a >>>>> trailing dash '-' for the bundle platform. >>>>> >>>>> I also fail to see where the dash before musl is added in the >>>>> version string? >>>>> >>>>> /Erik >>>>> >>>>> On 2017-04-13 18:02, Mikael Vidstedt wrote: >>>>>> With the introduction of musl - (and specifically >>>>>> linux-amd64) is no longer uniquely identifying the JDK platform >>>>>> and binaries. >>>>>> >>>>>> This change adds ?musl? in a couple of places: >>>>>> >>>>>> top: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/ >>>>>> >>>>>> hotspot: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> The two places are: >>>>>> >>>>>> 1. The bundle file names >>>>>> >>>>>> A typical linux-amd64 bundle today looks something like this: >>>>>> >>>>>> jdk-10-internal+0_linux-x64_bin.tar.gz >>>>>> >>>>>> At least for now, the ?normal?/gnu bundle file names will *not* be >>>>>> changed - only the new ?musl? ones will get the additional ?-musl? >>>>>> component: >>>>>> >>>>>> jdk-10-internal+0_linux-x64-musl_bin.tar.gz >>>>>> >>>>>> >>>>>> 2. The -Xinternalversion version string >>>>>> >>>>>> Much like with the bundle names, the current string looks >>>>>> something like: >>>>>> >>>>>> Java HotSpot(TM) 64-Bit Server VM >>>>>> (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64 >>>>>> JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr >>>>>> 13 2017 08:48:18 by "mikael" with gcc 4.9.2 >>>>>> >>>>>> This patch (only) adds ?-musl? for the musl version of the JVM, >>>>>> and leaves non-musl platforms unchanged. With musl the >>>>>> -Xinternalversion version string looks something like: >>>>>> >>>>>> Java HotSpot(TM) 64-Bit Server VM >>>>>> (10-internal+0-2017-04-10-172118.mikael.portola) for >>>>>> linux-amd64-musl JRE >>>>>> (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13 >>>>>> 2017 08:34:03 by "mikael" with gcc 4.9.2 >>>>>> >>>>>> but without the bold highlighting ;) >>>>>> >>>>>> >>>>>> As I mentioned in the thread [1] for the confstr/libc/libpthread >>>>>> patch I will take another round through the code after I have this >>>>>> in place and make sure everything is handled in a consistent manner. >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html >>>>>> >>>>>> >>>>> >>>> >> From josh at grahamis.com Thu Apr 27 01:14:26 2017 From: josh at grahamis.com (Josh Graham) Date: Thu, 27 Apr 2017 11:14:26 +1000 Subject: Bootstrap build of Portola on Alpine In-Reply-To: References: Message-ID: G'day Mikael, Out of curiosity, why did you have to do the poll.h softlink workaround? I > was naively hoping I had fixed all of the incorrect includes, but maybe I > missed something? > With warnings-as-errors the content of `sys/poll.h` emits a warning, thus raises an error. I suppose that flag could be turned off. There's a few -Xlint warnings, too, which may warrant further investigation. > bash ./configure --host=x86_64-unknown-linux-musl > --build=x86_64-unknown-linux-musl > Trying that now (along with a `make clean`). The new `--openjdk-target` argument looks interesting, I'll play with that too at some point. After I get a good build, I'll iterate from fresh and incorporate the `sed` idea and fewer package installs. Then it's on to runtime testing! Cheers, Josh From mikael.vidstedt at oracle.com Thu Apr 27 01:42:01 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 26 Apr 2017 18:42:01 -0700 Subject: Bootstrap build of Portola on Alpine In-Reply-To: References: Message-ID: <3EC8D413-EFA6-4F87-A6DF-2EDE6F40E095@oracle.com> > On Apr 26, 2017, at 6:14 PM, Josh Graham wrote: > > G'day Mikael, > > Out of curiosity, why did you have to do the poll.h softlink workaround? I >> was naively hoping I had fixed all of the incorrect includes, but maybe I >> missed something? >> > > With warnings-as-errors the content of `sys/poll.h` emits a warning, thus > raises an error. I suppose that flag could be turned off. There's a few > -Xlint warnings, too, which may warrant further investigation. Right, but I thought this change would have removed all the references to sys/poll.h (in favor of poll.h without the sys/ prefix): http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000009.html http://hg.openjdk.java.net/portola/portola/hotspot/rev/95d3f5d5ca24 http://hg.openjdk.java.net/portola/portola/jdk/rev/e5f4488e151b Which file is generating the warning/error? > > > >> bash ./configure --host=x86_64-unknown-linux-musl >> --build=x86_64-unknown-linux-musl >> > > Trying that now (along with a `make clean`). The new `--openjdk-target` > argument looks interesting, I'll play with that too at some point. Indeed. Erik/Magnus, can you comment on how the ?openjdk-target could/should be used here..? > After I get a good build, I'll iterate from fresh and incorporate the `sed` > idea and fewer package installs. Then it's on to runtime testing! Sounds great, let me know! Cheers, Mikael From erik.joelsson at oracle.com Thu Apr 27 07:25:50 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Apr 2017 09:25:50 +0200 Subject: Bootstrap build of Portola on Alpine In-Reply-To: <3EC8D413-EFA6-4F87-A6DF-2EDE6F40E095@oracle.com> References: <3EC8D413-EFA6-4F87-A6DF-2EDE6F40E095@oracle.com> Message-ID: <072673ee-2b5e-7a15-33aa-da8e318a4465@oracle.com> On 2017-04-27 03:42, Mikael Vidstedt wrote: > > > Indeed. Erik/Magnus, can you comment on how the ?openjdk-target > could/should be used here..? > It's not intended for this use case since it's a native build (build==host==target). We introduced that parameter as convenience for when cross compiling. OpenJDK developers found the notion of setting "--host" confusing so we introduced a new parameter that uses the term "target" which was more comfortable. /Erik From mikael.vidstedt at oracle.com Thu Apr 27 16:15:40 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 27 Apr 2017 09:15:40 -0700 Subject: Bootstrap build of Portola on Alpine In-Reply-To: <072673ee-2b5e-7a15-33aa-da8e318a4465@oracle.com> References: <3EC8D413-EFA6-4F87-A6DF-2EDE6F40E095@oracle.com> <072673ee-2b5e-7a15-33aa-da8e318a4465@oracle.com> Message-ID: <0F1231CA-7AC6-4D8C-8ECC-4DF95C171D71@oracle.com> > On Apr 27, 2017, at 12:25 AM, Erik Joelsson wrote: > > > > On 2017-04-27 03:42, Mikael Vidstedt wrote: >> >> >> Indeed. Erik/Magnus, can you comment on how the ?openjdk-target could/should be used here..? >> > It's not intended for this use case since it's a native build (build==host==target). We introduced that parameter as convenience for when cross compiling. OpenJDK developers found the notion of setting "--host" confusing so we introduced a new parameter that uses the term "target" which was more comfortable. Thanks for the clarification! Cheers, Mikael From mikael.vidstedt at oracle.com Thu Apr 27 22:59:14 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 27 Apr 2017 15:59:14 -0700 Subject: RFR: Change newly introduced CLIB variable names to LIBC In-Reply-To: References: Message-ID: <03438490-E08A-4471-8F36-00906CE7360C@oracle.com> Good catch, thanks! Cheers, Mikael > On Apr 26, 2017, at 5:39 PM, David Holmes wrote: > > You made a mistake in common/autoconf/buildjdk-spec.gmk.in > > -OPENJDK_TARGET_CLIB := @OPENJDK_BUILD_CLIB@ > +OPENJDK_TARGET_LIB := @OPENJDK_BUILD_LIBC@ > > Mising 'C' > > David > > On 27/04/2017 8:54 AM, Mikael Vidstedt wrote: >> >> Alan asked why I chose to use ?CLIB? for the various variable names/defines I introduced in autoconf/make/code/release file, rather than the much more reasonable ?LIBC?. He is, of course, totally right, so this change changes all the occurrences from CLIB to use LIBC instead: >> >> top: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/webrev/ >> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/hotspot/webrev/ >> jdk: http://cr.openjdk.java.net/~mikael/webrevs/portola/clib2libc/webrev.00/jdk/webrev/ >> >> Please have a look and verify the sanity of the changes! >> >> Cheers, >> Mikael >> From mikael.vidstedt at oracle.com Thu Apr 27 23:03:12 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 27 Apr 2017 23:03:12 +0000 Subject: hg: portola/portola: Change newly introduced CLIB variable names to LIBC Message-ID: <201704272303.v3RN3Coi003846@aojmv0008.oracle.com> Changeset: 60ab596f309c Author: mikael Date: 2017-04-27 16:00 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/60ab596f309c Change newly introduced CLIB variable names to LIBC ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! make/ReleaseFile.gmk From mikael.vidstedt at oracle.com Thu Apr 27 23:03:17 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 27 Apr 2017 23:03:17 +0000 Subject: hg: portola/portola/hotspot: Change newly introduced CLIB variable names to LIBC Message-ID: <201704272303.v3RN3H89003953@aojmv0008.oracle.com> Changeset: 60bfd8d0aba5 Author: mikael Date: 2017-04-27 16:00 -0700 URL: http://hg.openjdk.java.net/portola/portola/hotspot/rev/60bfd8d0aba5 Change newly introduced CLIB variable names to LIBC ! make/lib/CompileJvm.gmk ! src/share/vm/runtime/vm_version.cpp From mikael.vidstedt at oracle.com Thu Apr 27 23:03:22 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 27 Apr 2017 23:03:22 +0000 Subject: hg: portola/portola/jdk: Change newly introduced CLIB variable names to LIBC Message-ID: <201704272303.v3RN3NWv004011@aojmv0008.oracle.com> Changeset: 408aeb6498cc Author: mikael Date: 2017-04-27 16:00 -0700 URL: http://hg.openjdk.java.net/portola/portola/jdk/rev/408aeb6498cc Change newly introduced CLIB variable names to LIBC ! make/lib/CoreLibraries.gmk ! src/java.base/unix/native/libjli/java_md_solinux.c From mikael.vidstedt at oracle.com Thu Apr 27 23:06:56 2017 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 27 Apr 2017 23:06:56 +0000 Subject: hg: portola/portola: Regenerated autoconf script (using autogen.sh) Message-ID: <201704272306.v3RN6uFX005022@aojmv0008.oracle.com> Changeset: 7d46385f0500 Author: mikael Date: 2017-04-27 16:04 -0700 URL: http://hg.openjdk.java.net/portola/portola/rev/7d46385f0500 Regenerated autoconf script (using autogen.sh) ! common/autoconf/generated-configure.sh