From david.holmes at oracle.com Mon Jan 8 06:20:30 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 08 Jan 2018 06:20:30 +0000 Subject: hg: valhalla/valhalla: 108 new changesets Message-ID: <201801080620.w086KeAp000978@aojmv0008.oracle.com> Changeset: d4329843abf4 Author: darcy Date: 2017-12-18 18:51 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d4329843abf4 8173382: Add -source 11 and -target 11 to javac 8193291: Add SourceVersion.RELEASE_11 Reviewed-by: jjg, erikj, psandoz ! make/common/SetupJavaCompilers.gmk ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Profile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/LoadProc.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java ! test/langtools/ProblemList.txt ! test/langtools/tools/javac/api/T6265137.java ! test/langtools/tools/javac/api/T6395981.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java ! test/langtools/tools/javac/profiles/ProfileOptionTest.java ! test/langtools/tools/javac/versions/Versions.java Changeset: 89f6aa26fd6c Author: cushon Date: 2017-12-19 16:24 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/89f6aa26fd6c 8007720: Names are not loaded correctly for method parameters if the parameters have annotations 8177486: Incorrect handling of mandated parameter names in MethodParameters attributes Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/langtools/tools/javac/MethodParameters/ClassReaderTest/ClassReaderTest.java + test/langtools/tools/javac/MethodParameters/ClassReaderTest/ClassReaderTest.out + test/langtools/tools/javac/MethodParameters/ClassReaderTest/MethodParameterProcessor.java ! test/langtools/tools/javac/lib/DPrinter.java Changeset: 4966e9237b88 Author: dmarkov Date: 2017-12-13 14:41 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4966e9237b88 8154405: AccessControlException by URLPermission check Reviewed-by: serb, ssadetsky, mullan ! src/java.desktop/share/classes/java/awt/Toolkit.java Changeset: 1f38b6c89f8a Author: prr Date: 2017-12-13 10:56 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1f38b6c89f8a Merge - src/java.base/share/classes/java/lang/StringDecoderUTF8.java - test/java/util/Calendar/Bug8185841.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/TestMemberInheritence.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/diamond/A.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/diamond/B.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/diamond/C.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/diamond/X.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/diamond/Z.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/inheritDist/A.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/inheritDist/B.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/inheritDist/C.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/pkg/BaseClass.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/pkg/BaseInterface.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/pkg/SubClass.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/pkg1/Implementer.java - test/langtools/jdk/javadoc/doclet/testMemberInheritence/pkg1/Interface.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestBadOverride.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestMultiInheritence.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestOverrideMethods.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestOverridenMethodDocCopy.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethods.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg1/BaseClass.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg1/SubClass.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg2/SubClass.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg3/I0.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg3/I1.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg3/I2.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg3/I3.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg3/I4.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg4/Foo.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg5/Classes.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg5/Interfaces.java - test/langtools/jdk/javadoc/doclet/testOverridenMethods/pkg5/TestEnum.java Changeset: 4f9683bf0923 Author: rfield Date: 2017-12-13 14:21 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4f9683bf0923 8188894: jdk/jshell/ToolShiftTabTest.java failed with IllegalStateException Reviewed-by: jlahoda ! test/langtools/jdk/jshell/ToolShiftTabTest.java ! test/langtools/jdk/jshell/UITesting.java Changeset: ef097d7d5b15 Author: prr Date: 2017-12-18 10:28 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ef097d7d5b15 Merge - src/java.base/share/classes/java/util/zip/ZStreamRef.java - src/java.base/share/native/include/jvm.h - src/java.base/unix/native/include/jvm_md.h - src/java.base/windows/native/include/jvm_md.h - src/java.management/share/native/include/jmm.h - src/jdk.compiler/share/classes/com/sun/tools/javah/Gen.java - src/jdk.compiler/share/classes/com/sun/tools/javah/InternalError.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JNI.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JavahFileManager.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTool.java - src/jdk.compiler/share/classes/com/sun/tools/javah/LLNI.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Main.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Mangle.java - src/jdk.compiler/share/classes/com/sun/tools/javah/NativeHeaderTool.java - src/jdk.compiler/share/classes/com/sun/tools/javah/TypeSignature.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Util.java - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n.properties - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n_ja.properties - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/version.properties-template - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PackageListWriter.java - test/jdk/sun/security/tools/keytool/p12importks.sh - test/langtools/tools/javac/T8152360/DeprecateJavahTest.java - test/langtools/tools/javac/nativeHeaders/javahComparison/CompareTest.java - test/langtools/tools/javac/nativeHeaders/javahComparison/TestClass1.java - test/langtools/tools/javac/nativeHeaders/javahComparison/TestClass4.java - test/langtools/tools/javac/nativeHeaders/javahComparison/TestClass5.java - test/langtools/tools/javah/4942232/ParamClassTest.java - test/langtools/tools/javah/4942232/Test.java - test/langtools/tools/javah/6257087/T6257087.java - test/langtools/tools/javah/6572945/T6572945.java - test/langtools/tools/javah/6572945/TestClass1.java - test/langtools/tools/javah/6572945/TestClass2.java - test/langtools/tools/javah/6572945/TestClass3.java - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass1.h - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner1.h - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner2.h - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass2.h - test/langtools/tools/javah/6572945/gold/jni.file.1 - test/langtools/tools/javah/6572945/gold/jni.file.2 - test/langtools/tools/javah/6572945/gold/jni.file.3 - test/langtools/tools/javah/ModuleClass.java - test/langtools/tools/javah/ReadOldClass.sh - test/langtools/tools/javah/T4942232/MissingParamClassTest.java - test/langtools/tools/javah/T5070898.java - test/langtools/tools/javah/T6893943.java - test/langtools/tools/javah/T6994608.java - test/langtools/tools/javah/T7126832/T7126832.java - test/langtools/tools/javah/T7126832/java.java - test/langtools/tools/javah/T7185778.java - test/langtools/tools/javah/TestHelpOpts.java - test/langtools/tools/javah/VersionTest.java - test/langtools/tools/javah/constMacroTest/ConstMacroTest.java - test/langtools/tools/lib/toolbox/JavahTask.java Changeset: 3d4e8f5a2a69 Author: rfield Date: 2017-12-19 11:37 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3d4e8f5a2a69 8179858: jshell tool: sync nomenclature from reference to online /help Reviewed-by: dlsmith, jjg ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/langtools/jdk/jshell/CommandCompletionTest.java ! test/langtools/jdk/jshell/EditorTestBase.java ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java Changeset: 59adf939036a Author: prr Date: 2017-12-19 13:02 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/59adf939036a Merge Changeset: 80176afc8667 Author: prr Date: 2017-12-19 13:58 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/80176afc8667 Merge Changeset: 9b700a5c4381 Author: mcimadamore Date: 2017-12-20 15:33 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9b700a5c4381 8057650: uniform error diagnostics for inconsistent inherited method signatures Summary: consolidate diagnostics for bad overrides Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/BadCovar.out ! test/langtools/tools/javac/InconsistentInheritedSignature.out ! test/langtools/tools/javac/OverrideChecks/InconsistentReturn.out ! test/langtools/tools/javac/defaultMethods/Neg01.out ! test/langtools/tools/javac/defaultMethods/Neg02.out ! test/langtools/tools/javac/defaultMethods/Neg14.out ! test/langtools/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java ! test/langtools/tools/javac/diags/examples/TypesIncompatible.java ! test/langtools/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java ! test/langtools/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/langtools/tools/javac/generics/6294779/T6294779c.out ! test/langtools/tools/javac/generics/abstract/T4717181c.out ! test/langtools/tools/javac/generics/rawOverride/7157798/Test3.out ! test/langtools/tools/javac/generics/typevars/4856983/T4856983a.out ! test/langtools/tools/javac/generics/typevars/4856983/T4856983b.out ! test/langtools/tools/javac/generics/typevars/6199146/T6199146.out ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.out ! test/langtools/tools/javac/lambda/BadConv04.out ! test/langtools/tools/javac/lambda/bridge/template_tests/BridgeMethodsTemplateTest.java ! test/langtools/tools/javac/lambda/funcInterfaces/NonSAM2.out ! test/langtools/tools/javac/miranda/4711056/T1.out Changeset: 315c690bb90b Author: bpb Date: 2017-12-20 08:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/315c690bb90b 8193842: Replace Files.copy(InputStream,OutputStream) with InputStream.transferTo(OutputStream) Reviewed-by: clanger, alanb ! src/java.base/share/classes/java/nio/file/Files.java Changeset: c96d4c720995 Author: attila Date: 2017-12-20 17:36 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c96d4c720995 8193371: Use Dynalink REMOVE operation in Nashorn Reviewed-by: hannesw, sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + test/nashorn/script/basic/JDK-8193371.js + test/nashorn/script/basic/JDK-8193371.js.EXPECTED Changeset: 4944950606ef Author: psandoz Date: 2017-12-20 09:14 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4944950606ef 8191913: Bump classfile version number to 55 Reviewed-by: dholmes, darcy Contributed-by: paul.sandoz at oracle.com, erik.joelsson at oracle.com ! make/Main.gmk ! make/autoconf/buildjdk-spec.gmk.in ! make/autoconf/flags.m4 ! make/autoconf/generated-configure.sh ! make/autoconf/jdk-version.m4 ! make/autoconf/platform.m4 ! make/autoconf/spec.gmk.in ! make/autoconf/version-numbers ! make/copy/Copy-java.base.gmk ! make/copy/CopyCommon.gmk ! make/gensrc/GensrcX11Wrappers.gmk ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/share/classfile/classFileParser.cpp ! src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java - src/java.base/share/native/include/classfile_constants.h + src/java.base/share/native/include/classfile_constants.h.template ! src/java.base/share/native/libjava/System.c ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java ! src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java + test/hotspot/jtreg/runtime/classFileParserBug/Class55.jasm ! test/jdk/java/lang/module/ClassFileVersionsTest.java ! test/langtools/tools/javac/6330997/T6330997.java ! test/langtools/tools/javac/classfiles/ClassVersionChecker.java ! test/langtools/tools/javac/versions/Versions.java Changeset: 29e165bdf669 Author: psandoz Date: 2017-12-20 09:14 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/29e165bdf669 8193085: Vectorize the nio Buffer equals and compareTo implementations Reviewed-by: alanb ! src/hotspot/share/classfile/vmSymbols.hpp ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/java/nio/Buffer.java + src/java.base/share/classes/java/nio/BufferMismatch.java ! src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template ! src/java.base/share/classes/java/nio/Direct-X-Buffer-bin.java.template ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template ! src/java.base/share/classes/java/nio/StringCharBuffer.java ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! src/java.base/share/classes/java/util/Arrays.java - src/java.base/share/classes/java/util/ArraysSupport.java + src/java.base/share/classes/jdk/internal/util/ArraysSupport.java + test/jdk/java/nio/Buffer/EqualsCompareTest.java Changeset: 63fb11c1550d Author: dholmes Date: 2017-12-20 22:36 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/63fb11c1550d 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support Reviewed-by: alanb, sspitsyn ! make/conf/jib-profiles.js ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/langtools/TEST.ROOT ! test/nashorn/TEST.ROOT Changeset: 38493aecb3d1 Author: xuelei Date: 2017-12-21 05:51 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/38493aecb3d1 8193683: Increase the number of clones in the CloneableDigest Reviewed-by: coffeys, wetmore ! src/java.base/share/classes/sun/security/ssl/HandshakeHash.java Changeset: 91bd550551e0 Author: cushon Date: 2017-12-21 15:58 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/91bd550551e0 8193216: Filer should warn if processors redefine symbols from the classpath or sourcepath Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java + test/langtools/tools/javac/processing/warnings/TypeAlreadyExists/A.java + test/langtools/tools/javac/processing/warnings/TypeAlreadyExists/B.java + test/langtools/tools/javac/processing/warnings/TypeAlreadyExists/TestProcTypeAlreadyExistsWarning.java + test/langtools/tools/javac/processing/warnings/TypeAlreadyExists/warn.out Changeset: 2731c0ee46a9 Author: mchung Date: 2017-12-21 15:04 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2731c0ee46a9 8193780: (ref) Remove the undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ref/Reference.java ! test/jdk/java/lang/ref/ReferenceEnqueue.java Changeset: e5a3b905622e Author: mchung Date: 2017-12-21 15:18 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e5a3b905622e 8193767: Improve javadoc in ResourceBundle working with modules Reviewed-by: alanb, naoto ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java Changeset: 50b86b3974ae Author: thartmann Date: 2017-12-15 16:51 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/50b86b3974ae 8193608: Quarantine test/hotspot/jtreg/compiler/codegen/Test6896617.java until JDK-8193479 is fixed Summary: Added test to ProblemList.txt Reviewed-by: vlivanov ! test/hotspot/jtreg/ProblemList.txt Changeset: b6a8e9658abd Author: rehn Date: 2017-12-18 12:11 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b6a8e9658abd 8193514: UseMembar should not be obsoleted yet Reviewed-by: dcubed, acorn, mdoerr ! src/hotspot/share/runtime/arguments.cpp Changeset: a6531fb9392e Author: dholmes Date: 2017-12-19 17:31 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a6531fb9392e 8193840: Add compiler/c2/Test8007294.java to the problem list Reviewed-by: coleenp ! test/hotspot/jtreg/ProblemList.txt Changeset: 0f53d49bb74b Author: dholmes Date: 2017-12-22 15:23 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0f53d49bb74b 8194071: [Testbug] Update VMDeprecatedOptions test for obsolete/expired options Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 2c1af559e922 Author: bpb Date: 2017-12-22 14:00 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2c1af559e922 8193832: Performance of InputStream.readAllBytes() could be improved Summary: Read into a list of fixed-size buffers which are gathered at the end Reviewed-by: alanb, chegar, plevart, jrose, psandoz ! src/java.base/share/classes/java/io/InputStream.java ! test/jdk/java/io/InputStream/ReadAllBytes.java Changeset: 3a52333a5e57 Author: vromero Date: 2018-01-02 16:35 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3a52333a5e57 8187487: crash with classes with same binary name Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/NestedInnerClassNames.out + test/langtools/tools/javac/T8187487/CrashWithDuplicateClassNamesTest.java + test/langtools/tools/javac/T8187487/CrashWithDuplicateClassNamesTest.out + test/langtools/tools/javac/diags/examples/SameBinaryName.java Changeset: cb54a299aa91 Author: jjg Date: 2017-12-14 13:16 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cb54a299aa91 8193525: Intermittent failures of TestModulePackages.java Reviewed-by: darcy ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java Changeset: 8647aa05d094 Author: lana Date: 2017-12-15 16:38 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8647aa05d094 Added tag jdk-10+36 for changeset cb54a299aa91 ! .hgtags Changeset: cfde2a53d393 Author: roland Date: 2017-12-15 10:26 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cfde2a53d393 8193518: C2: Vector registers sometimes corrupted at safepoint Reviewed-by: neliasso, thartmann, kvn ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/superword.cpp Changeset: 291020144f22 Author: vdeshpande Date: 2017-12-15 10:44 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/291020144f22 8190934: Regressions on Haswell Xeon due to JDK-8178811 Reviewed-by: neliasso, kvn ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/library_call.cpp Changeset: a099e4d4c35b Author: dmarkov Date: 2017-12-15 21:49 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a099e4d4c35b 8154405: AccessControlException by URLPermission check Reviewed-by: serb, ssadetsky, mullan ! src/java.desktop/share/classes/java/awt/Toolkit.java Changeset: f9152f462cbc Author: alanb Date: 2017-12-19 10:03 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f9152f462cbc 8193758: Update copyright headers of files in src tree that are missing Classpath exception Reviewed-by: mchung, mr, jjg, iris, prr ! make/jdk/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! src/java.base/share/classes/java/lang/PublicMethods.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/invoke/StringConcatException.java ! src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaderValue.java ! src/java.base/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.c ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.h ! src/java.desktop/windows/native/common/awt/systemscale/systemScale.cpp ! src/java.desktop/windows/native/common/awt/systemscale/systemScale.h ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java Changeset: 865d39b662a5 Author: mbaesken Date: 2017-12-15 14:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/865d39b662a5 8193515: AIX: new Harfbuzz 1.7.1 version fails to compile with xlC Reviewed-by: prr, simonis ! src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh Changeset: 5471388067cf Author: sundar Date: 2017-12-19 21:35 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5471388067cf 8193779: Fix copyright header in nashorn builtin scripts Reviewed-by: alanb, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js ! test/nashorn/script/trusted/classfilter_mozilla_compat.js.EXPECTED Changeset: 41ae5c69b09c Author: michaelm Date: 2017-12-19 15:48 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/41ae5c69b09c 8192966: HttpClient should reuse TCP connection for h2c connections Reviewed-by: dfuchs ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Exchange.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/ExchangeImpl.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http2ClientImpl.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http2Connection.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/PlainHttpConnection.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/ResponseContent.java ! test/jdk/java/net/httpclient/http2/server/Http2TestServer.java Changeset: 4ffa14468cd1 Author: michaelm Date: 2017-12-19 16:12 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4ffa14468cd1 Merge Changeset: e8e8db4f8194 Author: mr Date: 2017-12-19 08:51 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e8e8db4f8194 8193764: Cannot set COMPANY_NAME when configuring a build Reviewed-by: erikj, martin, tbell ! make/autoconf/generated-configure.sh ! make/autoconf/jdk-version.m4 Changeset: 5382baab8371 Author: chegar Date: 2017-12-18 10:21 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5382baab8371 8193698: Null handling in BodyPublisher, BodyHandler, and BodySubscriber convenience static factory methods Reviewed-by: dfuchs ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/BufferingSubscriber.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpResponse.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/RequestPublishers.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/ResponseSubscribers.java - test/jdk/java/net/httpclient/RequestProcessorExceptions.java + test/jdk/java/net/httpclient/SubscriberPublisherAPIExceptions.java Changeset: 597f69e5f1e3 Author: hannesw Date: 2017-12-20 21:40 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/597f69e5f1e3 8193508: Expressions in split literals must never be optimistic Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGeneratorLexicalContext.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/GetSplitState.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ObjectNode.java + test/nashorn/script/basic/JDK-8193508.js Changeset: 8b434af2703d Author: sballal Date: 2017-12-08 15:41 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8b434af2703d 8193124: SA: Testcases for clhsdb jdis and findpc commands Reviewed-by: sundar, cjplummer, jgeorge + test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java + test/hotspot/jtreg/serviceability/sa/ClhsdbJdis.java Changeset: 0997d6959851 Author: dcubed Date: 2017-12-08 15:24 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0997d6959851 8193135: get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff Reviewed-by: stefank, gtriantafill, coleenp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/threadSMR.cpp ! src/hotspot/share/runtime/threadSMR.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java ! test/hotspot/jtreg/runtime/Thread/TestThreadDumpSMRInfo.java Changeset: d6388b652504 Author: ccheung Date: 2017-12-08 15:14 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d6388b652504 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) Summary: disable loading array classes from the class list Reviewed-by: iklam, jiangli ! src/hotspot/share/classfile/classListParser.cpp ! src/hotspot/share/classfile/classListParser.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java Changeset: ecff0c7bfb4d Author: jwilhelm Date: 2017-12-08 23:43 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ecff0c7bfb4d Merge - test/langtools/jdk/javadoc/doclet/testBadPackageFileInJar/badPackageFileInJar.jar - test/langtools/jdk/javadoc/doclet/testGroupOption/C.java - test/langtools/tools/javac/T5090006/AssertionFailureTest.java - test/langtools/tools/javac/T5090006/broken.jar Changeset: 589a6f1d86e9 Author: cjplummer Date: 2017-12-09 07:50 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/589a6f1d86e9 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError Summary: call FindClass() when we are in the proper classloader context Reviewed-by: sspitsyn, dholmes, amenkov ! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/libGetOwnedMonitorInfoTest.c Changeset: ed1bb7743b3e Author: thartmann Date: 2017-12-12 19:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ed1bb7743b3e 8193363: TestDumpReplay.java fails with product builds Summary: Added missing -XX:+IgnoreUnrecognizedVMOptions Reviewed-by: kvn ! test/hotspot/jtreg/compiler/ciReplay/TestDumpReplay.java Changeset: 7daebcef2e0d Author: coleenp Date: 2017-12-12 11:55 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7daebcef2e0d 8193386: CompressedClassSize too large with MaxMetaspace Reviewed-by: ysuenaga, coleenp Contributed-by: manc at google.com ! src/hotspot/share/memory/metaspace.cpp Changeset: a576e1b6784d Author: coleenp Date: 2017-12-12 14:14 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a576e1b6784d Merge Changeset: 7b1a9b267a94 Author: dcubed Date: 2017-12-12 21:27 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7b1a9b267a94 8193407: jdk/hs fails Solaris slowdebug test-image build Summary: Add a missing '-lc' option for libCNLookUp. Reviewed-by: dholmes, kvn ! make/test/JtregNativeHotspot.gmk Changeset: fe6fb69336b5 Author: dholmes Date: 2017-12-12 19:06 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fe6fb69336b5 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls Reviewed-by: coleenp, dcubed ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/prims/jniCheck.cpp + test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedEnsureLocalCapacity.c Changeset: d3b6470a6dec Author: dholmes Date: 2017-12-12 21:43 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d3b6470a6dec Merge ! make/test/JtregNativeHotspot.gmk Changeset: 10ec0c43cf1d Author: bchristi Date: 2017-12-08 13:04 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/10ec0c43cf1d 8193271: ProblemList tools/launcher/TestXcheckJNIWarnings.java Reviewed-by: darcy ! test/jdk/ProblemList.txt Changeset: 993b004ab38f Author: bchristi Date: 2017-12-12 21:46 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/993b004ab38f 8190984: tools/launcher/TestXcheckJNIWarnings.java WARNING was found in the output Reviewed-by: dholmes, mchung ! src/java.base/share/native/libjava/System.c ! test/jdk/ProblemList.txt Changeset: 39a84de6afd6 Author: neliasso Date: 2017-12-13 10:21 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/39a84de6afd6 8192971: LockCompilationTest fails intermittently Summary: Remove all unnecessary compilations Reviewed-by: kvn, thartmann ! test/hotspot/jtreg/compiler/whitebox/LockCompilationTest.java Changeset: 919780ab7acc Author: coleenp Date: 2017-12-13 07:14 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/919780ab7acc 8193053: jvm crash by G1CMBitMapClosure::do_addr Summary: We were adding an unloaded mirror to the SATB collection set in remove_handle. Reviewed-by: hseigel, kbarrett ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp Changeset: 3c9975e46464 Author: vlivanov Date: 2017-12-13 19:32 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3c9975e46464 8190869: C2: missing strength reduction of Math.pow(x, 2.0D) to x*x Reviewed-by: kvn ! src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: ead47ddf5844 Author: kvn Date: 2017-12-13 11:59 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ead47ddf5844 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line Summary: skip tests which use --limit-modules when Graal is used as JIT compiler. Reviewed-by: alanb, mchung, dholmes, ccheung, dnsimon ! .hgignore ! test/hotspot/jtreg/runtime/SharedArchiveFile/BootAppendTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/limitmods/LimitModsTests.java ! test/jdk/TEST.ROOT ! test/jdk/com/sun/tools/attach/modules/Driver.java ! test/jdk/java/lang/String/concat/WithSecurityManager.java ! test/jdk/java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java ! test/jdk/java/lang/instrument/TestAgentWithLimitMods.java ! test/jdk/java/lang/management/ManagementFactory/DefaultManagementProviderTest.java ! test/jdk/java/net/SocketOption/OptionsTest.java ! test/jdk/java/net/SocketOption/UnsupportedOptionsTest.java ! test/jdk/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/jdk/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/jdk/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/jdk/tools/launcher/modules/limitmods/LimitModsTest.java ! test/jdk/tools/launcher/modules/listmods/ListModsTest.java ! test/jdk/tools/launcher/modules/showmoduleresolution/ShowModuleResolutionTest.java Changeset: 79afa4c434f6 Author: iveresov Date: 2017-12-13 12:28 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/79afa4c434f6 8193439: Update Graal Reviewed-by: kvn ! src/jdk.internal.vm.compiler/.mx.graal/suite.py ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64LIRKindTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/LIRKind.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/CompilationAlarm.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCLIRKindTool.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CountedLoopTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/Assertions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Graph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLIRKindTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLIRGenerator.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CRC32CSubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/JVMCIInfopointErrorTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotReferenceMapBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/CRC32CSubstitutions.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/bytecode/BC_idiv_overflow.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/bytecode/BC_ldiv_overflow.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/IfNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerDivRemNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ProfileCompiledMethodsPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/GraphPrinter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/GraphEffectList.java Changeset: cf7792800ba9 Author: jwilhelm Date: 2017-12-13 23:06 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cf7792800ba9 Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java ! test/jdk/ProblemList.txt ! test/jdk/TEST.ROOT Changeset: 8604408bc26e Author: dlong Date: 2017-12-13 20:35 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8604408bc26e 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler Reviewed-by: kvn ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Changeset: be065f758154 Author: jgeorge Date: 2017-12-14 12:49 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/be065f758154 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands Summary: Create tests for the clhsdb commands: inspect, scanoops and printas Reviewed-by: sspitsyn, sballal, cjplummer + test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java + test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAs.java + test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java Changeset: 945332d45710 Author: lkorinth Date: 2017-12-06 11:11 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/945332d45710 8133805: Remove the bot_updates parameter from G1Allocator's allocation methods Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp Changeset: 6d4e1efac80a Author: iklam Date: 2017-12-13 15:37 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6d4e1efac80a 8165603: runtime/appcds/UseAppCDS.java: failed to clean up files after test when running with agentvm Reviewed-by: mseledtsov, dholmes ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/appcds/MultiReleaseJars.java ! test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/appcds/UseAppCDS.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java ! test/hotspot/jtreg/runtime/appcds/test-classes/Util.java Changeset: 177e1783d886 Author: jwilhelm Date: 2017-12-20 20:55 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/177e1783d886 Merge ! src/hotspot/share/opto/library_call.cpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java Changeset: 5f1c30b80554 Author: coleenp Date: 2017-12-19 15:56 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5f1c30b80554 8193622: JFR test TestUnloadingEventClass.java times out intermittently Summary: Previous change was leaving scratch classes on CLD::_klasses list which are reported to tracing Reviewed-by: gtriantafill, dcubed, mgronlun ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: 26b47ea4c77d Author: jjg Date: 2017-12-20 13:28 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/26b47ea4c77d 8193512: Remove remnants of javah from jdk/jdk repo Reviewed-by: tbell, erikj, alanb, darcy ! make/Images.gmk ! make/RunTestsPrebuiltSpec.gmk ! make/autoconf/boot-jdk.m4 ! make/autoconf/bootcycle-spec.gmk.in ! make/autoconf/generated-configure.sh ! make/autoconf/spec.gmk.in ! make/common/JavaCompilation.gmk ! make/gensrc/Gensrc-jdk.compiler.gmk ! make/langtools/build.properties ! make/langtools/build.xml - make/langtools/intellij/runConfigurations/javah.xml ! make/langtools/netbeans/README ! make/langtools/test/HelloWorld.apt.gold.txt ! make/langtools/test/HelloWorld.java - make/langtools/test/bootstrap/javah.sh ! make/langtools/test/contents.gold.txt ! make/langtools/test/lib/classes.gold.txt - make/langtools/test/lib/javah.sh ! make/langtools/test/lib/src.gold.txt ! make/langtools/tools/anttasks/SelectToolTask.java ! make/nb_native/nbproject/configurations.xml ! make/scripts/compare_exceptions.sh.incl Changeset: fcb5b835bf32 Author: hannesw Date: 2017-12-21 10:26 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fcb5b835bf32 8193491: JavaImporter fails to resolve method elements within functions, that contain too many statements Reviewed-by: hannesw, sundar, jlaskey Contributed-by: priya.lakshmi.muthuswamy at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJavaImporter.java ! test/nashorn/script/basic/JDK-8011555.js.EXPECTED + test/nashorn/script/basic/JDK-8193491.js + test/nashorn/script/basic/JDK-8193491.js.EXPECTED ! test/nashorn/script/nosecurity/JDK-8165198.js ! test/nashorn/script/nosecurity/JDK-8165198.js.EXPECTED Changeset: 4f830b447edf Author: chegar Date: 2017-12-21 16:58 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4f830b447edf 8193365: Improve interoperability between HTTP Client's BodyPublisher/BodySubscriber and Flow.Subscriber/Publisher Reviewed-by: dfuchs ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpRequest.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpResponse.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/RequestPublishers.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/ResponseSubscribers.java + test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java + test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java + test/jdk/java/net/httpclient/FlowAdaptersCompileOnly.java Changeset: 5ab69533994b Author: joehw Date: 2017-12-21 09:29 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5ab69533994b 8193568: @LastModified tag in license header Reviewed-by: rriggs ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Utility.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ARRAYLENGTH.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ATHROW.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/IDIV.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/IREM.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LDIV.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LREM.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/MONITORENTER.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/MONITOREXIT.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/MethodGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/NEWARRAY.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ReturnInstruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELFactory.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDatetime.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLMessages.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/ConfigurationError.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/Translet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BinOpExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CallTemplate.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CeilingCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ConcatCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ContainsCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/DocumentCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ElementAvailableCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Expression.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FloorCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FlowList.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FormatNumberCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionAvailableCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/GenerateIdCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LangCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LocalNameCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LogicalExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Message.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NameBase.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NameCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceUriCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NotCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NumberCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Predicate.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstructionPattern.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelationalExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RoundCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Sort.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StartsWithCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Step.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StepPattern.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StringCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StringLengthCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TopLevelElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnaryOpExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnionPathExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnparsedEntityUriCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UseAttributeSets.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableBase.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Whitespace.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathLexer.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/BooleanType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/IntType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/InternalError.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSetType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RealType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ReferenceType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ResultTreeType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringStack.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Type.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/VoidType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeCounter.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecordFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/InternalRuntimeError.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/TransletOutputHandlerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/XSLTCSource.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/AttributeMap.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationSourceImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMNormalizer.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMStringListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMXSImplementationSourceImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeepNodeListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentTypeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/RangeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNamespaceBinder.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDDescription.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDLoader.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDProcessor.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/DFAContentModel.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/XSFacets.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/Base64.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/ByteListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseDVFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/ExtendedSchemaDVFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/FullDVFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/ListDV.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDVFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDecl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ConfigurableValidationState.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ValidationManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ValidationState.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/PSVIErrorList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaGrammar.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSComplexTypeDecl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSConstraints.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSModelImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMBuilder.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSAllCM.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSDFACM.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSEmptyCM.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOM.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/StAXSchemaParser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractTraverser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDElementTraverser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDSimpleTypeTraverser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDUniqueOrKeyTraverser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDocumentInfo.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/LSInputListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/ObjectListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/ShortListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/StringListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSGrammarPool.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMapImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSObjectListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/UnparsedEntityHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultBuilder.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/SimpleXMLSchema.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/SoftReferenceGrammarPool.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WeakReferenceXMLSchema.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WrappedSAXException.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractDOMParser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/BasicParserConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11DTDConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11NonValidatingConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMEntityResolverWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/JAXPNamespaceContextWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/NamespaceSupport.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolHash.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/ConfigurationError.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/MultipleScopeNamespaceSupport.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeTextReader.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xni/Augmentations.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xni/NamespaceContext.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/LSInputList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/ShortList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/StringList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamedMap.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamespaceItemList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/XSObjectList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/ByteList.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/ObjectList.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBase.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMManagerDefault.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeList.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMStringPool.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTM.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2RTFDTM.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLMessages.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/CharInfo.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/NamespaceMappings.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToSAXHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/XSLOutputAttributes.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMStringListImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/NamespaceSupport.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Messages.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/URI.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/DOMBuilder.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/ObjectPool.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/QName.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/StringComparable.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/StylesheetPIHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/URI.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/Expression.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/ExtensionsProvider.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSet.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/SourceTreeManager.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/VariableStack.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPath.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPathContext.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPathException.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/AxesWalker.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprIterator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprIteratorSimple.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/IteratorPool.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/LocPathIterator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/MatchPatternIterator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/NodeSequence.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/PredicatedNodeTest.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/UnionChildIterator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/UnionPathIterator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/WalkingIterator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/WalkingIteratorSorted.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/OpMap.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCurrent.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtFunction.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncFalse.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncHere.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLast.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncPosition.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncTrue.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/Function2Args.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/Function3Args.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionMultiArgs.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionOneArg.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/objects/XNodeSet.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/objects/XObject.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/operations/Operation.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/operations/UnaryOperation.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/operations/Variable.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/patterns/ContextMatchStepPattern.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/patterns/FunctionPattern.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/patterns/NodeTest.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/patterns/StepPattern.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/patterns/UnionPattern.java Changeset: 8aab0cea56bf Author: psandoz Date: 2017-12-20 11:40 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8aab0cea56bf 8193856: takeWhile produces incorrect result with elements produced by flatMap Reviewed-by: smarks ! src/java.base/share/classes/java/util/stream/WhileOps.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java Changeset: 4ff5c5206427 Author: attila Date: 2017-12-20 17:36 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4ff5c5206427 8193371: Use Dynalink REMOVE operation in Nashorn Reviewed-by: hannesw, sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + test/nashorn/script/basic/JDK-8193371.js + test/nashorn/script/basic/JDK-8193371.js.EXPECTED Changeset: d4412e380f6b Author: joehw Date: 2017-12-21 17:08 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d4412e380f6b 8184431: References to @sun.com Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ElementImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/JAXPValidatorComponent.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/TeeXMLDocumentFilterImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DraconianErrorHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ErrorHandlerAdaptor.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ReadOnlyGrammarPool.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/Util.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WrappedSAXException.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DraconianErrorHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/ErrorHandlerProxy.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/LocatorWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/NamespaceContextWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SAX2XNI.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TeeXMLDocumentFilterImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/XMLDocumentFilterImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/XMLInputSourceAdaptor.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/XML11Serializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPVariableStack.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLBufferListener.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/LocationImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/NamespaceImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/NotationDeclarationImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/XMLEventFactoryImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/util/BufferAllocator.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/util/ThreadLocalBufferAllocator.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/UTF8OutputStreamWriter.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/java.xml/share/classes/javax/xml/XMLConstants.java ! src/java.xml/share/classes/javax/xml/datatype/DatatypeConfigurationException.java ! src/java.xml/share/classes/javax/xml/datatype/DatatypeConstants.java ! src/java.xml/share/classes/javax/xml/datatype/DatatypeFactory.java ! src/java.xml/share/classes/javax/xml/datatype/Duration.java ! src/java.xml/share/classes/javax/xml/datatype/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/datatype/XMLGregorianCalendar.java ! src/java.xml/share/classes/javax/xml/datatype/package-info.java ! src/java.xml/share/classes/javax/xml/namespace/NamespaceContext.java ! src/java.xml/share/classes/javax/xml/namespace/QName.java ! src/java.xml/share/classes/javax/xml/parsers/DocumentBuilder.java ! src/java.xml/share/classes/javax/xml/parsers/DocumentBuilderFactory.java ! src/java.xml/share/classes/javax/xml/parsers/FactoryConfigurationError.java ! src/java.xml/share/classes/javax/xml/parsers/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/parsers/ParserConfigurationException.java ! src/java.xml/share/classes/javax/xml/parsers/SAXParser.java ! src/java.xml/share/classes/javax/xml/parsers/SAXParserFactory.java ! src/java.xml/share/classes/javax/xml/stream/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/transform/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/transform/Result.java ! src/java.xml/share/classes/javax/xml/transform/Transformer.java ! src/java.xml/share/classes/javax/xml/transform/TransformerFactory.java ! src/java.xml/share/classes/javax/xml/transform/dom/DOMResult.java ! src/java.xml/share/classes/javax/xml/transform/dom/DOMSource.java ! src/java.xml/share/classes/javax/xml/transform/overview.html ! src/java.xml/share/classes/javax/xml/transform/sax/SAXResult.java ! src/java.xml/share/classes/javax/xml/transform/sax/SAXSource.java ! src/java.xml/share/classes/javax/xml/transform/stax/StAXResult.java ! src/java.xml/share/classes/javax/xml/transform/stax/StAXSource.java ! src/java.xml/share/classes/javax/xml/transform/stream/StreamResult.java ! src/java.xml/share/classes/javax/xml/transform/stream/StreamSource.java ! src/java.xml/share/classes/javax/xml/validation/Schema.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactory.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactoryFinder.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactoryLoader.java ! src/java.xml/share/classes/javax/xml/validation/TypeInfoProvider.java ! src/java.xml/share/classes/javax/xml/validation/Validator.java ! src/java.xml/share/classes/javax/xml/validation/ValidatorHandler.java ! src/java.xml/share/classes/javax/xml/xpath/XPath.java ! src/java.xml/share/classes/javax/xml/xpath/XPathConstants.java ! src/java.xml/share/classes/javax/xml/xpath/XPathException.java ! src/java.xml/share/classes/javax/xml/xpath/XPathExpression.java ! src/java.xml/share/classes/javax/xml/xpath/XPathExpressionException.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactory.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryConfigurationException.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryFinder.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFunction.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFunctionException.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFunctionResolver.java ! src/java.xml/share/classes/javax/xml/xpath/XPathVariableResolver.java Changeset: c9e503d6fef5 Author: lana Date: 2017-12-22 01:27 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c9e503d6fef5 Added tag jdk-10+37 for changeset 4f830b447edf ! .hgtags Changeset: ca64a6be0128 Author: lana Date: 2017-12-22 01:28 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ca64a6be0128 Merge Changeset: bae005a497a2 Author: jcbeyler Date: 2017-12-20 08:38 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/bae005a497a2 8191988: JDK-8190862 work for arch s390 Summary: Cleanup interpreter TLAB code and fix ZeroTLAB Reviewed-by: mdoerr, goetz ! src/hotspot/cpu/s390/templateTable_s390.cpp Changeset: 08144d9cbdaa Author: dmarkov Date: 2017-12-22 18:49 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/08144d9cbdaa 8193435: Remove pre-1.2 SecurityManager text from java.awt.Toolkit Reviewed-by: serb, mullan ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/image/URLImageSource.java Changeset: 044979e94c4e Author: dlong Date: 2017-12-22 22:01 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/044979e94c4e 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 Reviewed-by: kvn ! src/hotspot/share/ci/ciField.cpp Changeset: 2207e2917a68 Author: dlong Date: 2017-12-22 22:06 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2207e2917a68 8191854: Null pointer dereference in methodData.hpp:462 Reviewed-by: kvn ! src/hotspot/share/runtime/compilationPolicy.cpp Changeset: 8441a7cea1c1 Author: rraghavan Date: 2017-12-26 00:38 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8441a7cea1c1 8193699: aarch64 fails to build after 8167372 Summary: added ThreadInVMfromUnknown support Reviewed-by: smonteith, vlivanov ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: b54852746e8f Author: sballal Date: 2017-12-26 15:53 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b54852746e8f 8193427: serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr Reviewed-by: dholmes, sspitsyn ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java Changeset: 240933cf3758 Author: sballal Date: 2017-12-27 11:26 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/240933cf3758 8193428: serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr Reviewed-by: dholmes, sspitsyn ! test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java Changeset: cafc0ddb8db3 Author: shurailine Date: 2018-01-02 09:56 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cafc0ddb8db3 8192837: Need new test for release info file Summary: Detect when OpenJDK is built with ClosedJDK elements Reviewed-by: erikj, dholmes, martin Contributed-by: randy.crihfield at oracle.com + test/jdk/sanity/releaseFile/NegativeSOURCETest.java Changeset: 35cf3c947420 Author: jjg Date: 2018-01-02 16:07 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/35cf3c947420 8183964: Bad lexing of javadoc comments (change in parsing/rendering of backslashes in javadoc) Reviewed-by: vromero, cushon ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! test/langtools/tools/javac/parser/T4910483.java Changeset: 8749f0b3d227 Author: sballal Date: 2018-01-03 10:55 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8749f0b3d227 8193506: serviceability/sa/TestClassDump.java fails in OpenJDK build Reviewed-by: dholmes, cjplummer ! test/hotspot/jtreg/serviceability/sa/TestClassDump.java Changeset: fcd1913b1d36 Author: sballal Date: 2018-01-03 11:14 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fcd1913b1d36 8194058: [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output Reviewed-by: dholmes, cjplummer ! test/hotspot/jtreg/serviceability/sa/ClhsdbWhere.java Changeset: c08f1067ef57 Author: sveerabhadra Date: 2018-01-03 15:37 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c08f1067ef57 8193468: [PIT][TEST BUG]: java/awt/FileDialog/MoveToTrashTest.java fails on Linux Reviewed-by: aghaisas, serb ! test/jdk/java/awt/FileDialog/MoveToTrashTest.java Changeset: b08405cc467a Author: jjg Date: 2018-01-03 11:10 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b08405cc467a 8193125: javac should not compile a module if it requires java.base with modifiers Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples.not-yet.txt + test/langtools/tools/javac/diags/examples/ModifierNotAllowed/module-info.java + test/langtools/tools/javac/modules/JavaBaseTest.java ! test/langtools/tools/javac/processing/model/util/printing/module-info.java ! test/langtools/tools/javac/processing/model/util/printing/module-info.out Changeset: e569e83139fd Author: goetz Date: 2018-01-03 14:41 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e569e83139fd 8194482: Fix SIGSEGV in print_threads_compiling. Reviewed-by: kvn ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: e9a564028f2f Author: joehw Date: 2018-01-03 18:21 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e9a564028f2f 8189704: broken links in the javax/xml/namespace package Reviewed-by: darcy ! src/java.xml/share/classes/javax/xml/XMLConstants.java ! src/java.xml/share/classes/javax/xml/namespace/NamespaceContext.java ! src/java.xml/share/classes/javax/xml/namespace/QName.java Changeset: 68c6f57c40d4 Author: lana Date: 2018-01-04 04:22 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/68c6f57c40d4 Merge ! .hgtags ! make/autoconf/generated-configure.sh ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in - src/java.base/share/classes/java/util/ArraysSupport.java - src/java.base/share/native/include/classfile_constants.h ! src/java.base/share/native/libjava/System.c ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/TEST.ROOT Changeset: b2cd597479ea Author: alanb Date: 2018-01-04 15:50 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b2cd597479ea 8194644: Typo in ModuleDescriptor.read javadoc Reviewed-by: alanb Contributed-by: christoph.dreis at freenet.de ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java Changeset: db09f53aba91 Author: ksrini Date: 2018-01-03 15:16 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/db09f53aba91 8193671: Default Methods tab under Method Summary includes static methods Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/pkg1/A.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/pkg1/B.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/pkg1/D.java Changeset: 04d8d293e458 Author: jjg Date: 2018-01-04 10:14 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/04d8d293e458 8194141: Remove JDK9Wrappers Reviewed-by: erikj, alanb ! make/autoconf/spec.gmk.in ! src/java.base/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.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 - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java Changeset: 2d250a0174a6 Author: jjiang Date: 2018-01-04 19:58 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2d250a0174a6 8189760: sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with unexpected Exception intermittently Summary: Adds synchronization to make sure the server exception is available Reviewed-by: xuelei ! test/jdk/sun/security/ssl/CertPathRestrictions/JSSEServer.java ! test/jdk/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java Changeset: 20fe8cd3179d Author: bpb Date: 2018-01-05 12:45 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/20fe8cd3179d 8193861: Typos in API documentation of File.toPath() and InetSocketAddress.getAddress() Reviewed-by: chegar, rriggs, lancea ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/net/InetSocketAddress.java Changeset: 45a9a7a49379 Author: bpb Date: 2018-01-05 12:46 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/45a9a7a49379 8194649: Minor cleanup of parameter checking in ByteArrayOutputStream and ObjectInputStream Reviewed-by: rriggs ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/ObjectInputStream.java Changeset: dd3b97564ed7 Author: bpatel Date: 2018-01-04 09:22 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/dd3b97564ed7 8192007: javadoc @uses and @provides tags in the modules documentation appears before the first-sentence summary of the service type. Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java Changeset: efb9f4c91bde Author: goetz Date: 2017-12-27 11:31 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/efb9f4c91bde 8194232: Container memory not properly recognized. Reviewed-by: bobv, mdoerr, acorn ! src/hotspot/os/linux/osContainer_linux.cpp Changeset: b39894f95ab8 Author: bobv Date: 2018-01-04 13:41 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b39894f95ab8 Merge Changeset: f91345a216c9 Author: rfield Date: 2018-01-04 12:24 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f91345a216c9 8179858: jshell tool: sync nomenclature from reference to online /help Reviewed-by: dlsmith, jjg ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/langtools/jdk/jshell/CommandCompletionTest.java ! test/langtools/jdk/jshell/EditorTestBase.java ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java Changeset: 9c37fbceb579 Author: jjg Date: 2018-01-04 12:55 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9c37fbceb579 8194069: doclint throws missing comment warnings on lines which can't even have javadoc Reviewed-by: ksrini ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java + test/langtools/tools/doclint/LambdaTest.java Changeset: 3b00541635f9 Author: ksrini Date: 2018-01-04 13:32 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3b00541635f9 8193671: Default Methods tab under Method Summary includes static methods Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/pkg1/A.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/pkg1/B.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/pkg1/D.java Changeset: 8935285e8759 Author: iveresov Date: 2018-01-04 14:44 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8935285e8759 8194271: jaotc crashes with --debug flag Reviewed-by: kvn, thartmann ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTBackend.java + test/hotspot/jtreg/compiler/aot/cli/jaotc/CompileClassWithDebugTest.java Changeset: a97a26eb896f Author: thartmann Date: 2018-01-05 10:23 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a97a26eb896f 8194494: SHA-512 stub uses AVX 2 instructions on non-supporting CPUs Summary: Check for supports_avx2() && supports_bmi2() before generating SHA-512 stub. Reviewed-by: kvn ! src/hotspot/cpu/x86/vm_version_x86.cpp Changeset: cb7926b6b3d6 Author: jjg Date: 2018-01-05 12:41 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cb7926b6b3d6 8188649: javadoc -encoding doesn't work when using the old doclet API Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java + test/langtools/jdk/javadoc/tool/EncodingTest.java + test/langtools/tools/javadoc/EncodingTest.java Changeset: fe391f235400 Author: lana Date: 2018-01-05 20:09 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fe391f235400 Added tag jdk-10+38 for changeset e569e83139fd ! .hgtags Changeset: 2ad215f9fdcf Author: lana Date: 2018-01-05 20:10 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2ad215f9fdcf Merge Changeset: ccbf1c998dd9 Author: lana Date: 2018-01-05 20:58 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ccbf1c998dd9 Merge Changeset: e2b8009bf42c Author: jjg Date: 2018-01-05 16:49 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e2b8009bf42c 8191637: Interface with defaults invalid compiler warning for Serializable Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.java + test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.out - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out Changeset: c10b8e775610 Author: lana Date: 2018-01-06 01:13 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c10b8e775610 Merge ! .hgtags - src/java.base/share/classes/java/util/ArraysSupport.java - src/java.base/share/native/include/classfile_constants.h - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java From david.holmes at oracle.com Mon Jan 8 07:09:00 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 08 Jan 2018 07:09:00 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <201801080709.w08790SP016291@aojmv0008.oracle.com> Changeset: 6b5376a862a7 Author: dholmes Date: 2018-01-08 02:04 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6b5376a862a7 Merge - make/langtools/intellij/runConfigurations/javah.xml - make/langtools/test/bootstrap/javah.sh - make/langtools/test/lib/javah.sh ! src/hotspot/share/ci/ciField.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmSymbols.hpp - src/java.base/share/classes/java/util/ArraysSupport.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java - src/java.base/share/native/include/classfile_constants.h ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java ! test/jdk/ProblemList.txt - test/jdk/java/net/httpclient/RequestProcessorExceptions.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out From tobias.hartmann at oracle.com Mon Jan 8 10:21:54 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 8 Jan 2018 11:21:54 +0100 Subject: RFR(S): 8193501: [MVT] Compilation fails with "unexpected projection from allocation node" In-Reply-To: References: Message-ID: <3430bc8e-cfa7-abad-c950-698bacd4febd@oracle.com> Hi Roland, for the record: looks good to me too :) Best regards, Tobias On 19.12.2017 16:03, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8193501/webrev.00/ > > This modifies CallNode::extract_projections() so it collects all results > (for calls that return multiple results) and fixes the code that uses > CallNode::extract_projections(). > > Roland. > From rwestrel at redhat.com Mon Jan 8 14:43:58 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 08 Jan 2018 15:43:58 +0100 Subject: RFR(S): 8193501: [MVT] Compilation fails with "unexpected projection from allocation node" In-Reply-To: <3430bc8e-cfa7-abad-c950-698bacd4febd@oracle.com> References: <3430bc8e-cfa7-abad-c950-698bacd4febd@oracle.com> Message-ID: > for the record: looks good to me too :) Thanks for looking at this, Tobias. Roland. From david.holmes at oracle.com Tue Jan 9 04:50:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Jan 2018 14:50:38 +1000 Subject: [Nestmates] RFR: 8191114: [Nestmates] Update access control exception handling and other features per final JVMS proposal In-Reply-To: <40d4b71c-b575-0488-7813-57fe4d17886a@oracle.com> References: <6a881d3a-9e99-781b-3910-0afd38715d39@oracle.com> <51652ef4-5dc3-4a87-748c-b0d6e6084b6a@oracle.com> <40d4b71c-b575-0488-7813-57fe4d17886a@oracle.com> Message-ID: <962fd37e-33e5-e163-2c13-67690196db30@oracle.com> Merged with latest jdk/jdk code. The jcod files are now defined as classfile version 55 - their final value. The nestmate logic is currently still enabled for JDK 10+ - I will bump that to 11 once the actual JDK version is bumped. I also want to clarify that these updates relate primarily to the actual nestmate implementation. There are changes proposed in the JVMS that affect the behaviour in cases that need not involve nestmates. Those changes are still under discussion and any necessary implementation and test changes will be made once those discussions are finalized. Also something I should have called out is the changes to the SelectionResolution test InvokeInterfaceICCE. With the changes to allow invokeinterface for private methods, there is one test group that no longer fails as expected and has been removed. I've placed it in InvokeInterfaceSuccess but it is commented out as it doesn't succeed. It seems to be some subset of the tests in that "group" that need to be modified but the SelectionResolution tests are not easily understood or adapted in that way. I will file a follow up issue for this. I'll let this sit for a day or so before pushing. I'm not expecting active reviews and I need to move on. Thanks, David On 15/12/2017 6:56 PM, David Holmes wrote: > And updated in place to merge in the classfile version 54 changes - all > jcod files needed updating. > > David > > On 15/12/2017 5:48 PM, David Holmes wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8191114/webrev.v1/ >> >> Only difference is classFileParser.cpp. The nestmate attributes should >> only be processed in a Java 10 (for now) version classfile. >> >> Thanks, >> David >> >> On 13/12/2017 5:31 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191114 >>> webrev: http://cr.openjdk.java.net/~dholmes/8191114/webrev/ >>> >>> The final proposed changes to the JVMS have been discussed by the EG >>> and it is time to bring everything into line with the proposed spec. >>> >>> The main changes are: >>> - Process for determining the nest-host has changed, specifically: >>> ?? - same package check is done first** >>> ?? - IncompatibleClassChangeError is thrown instead of >>> IllegalAccessError >>> - A self-reference is permitted in the NestMembers array >>> - A self-reference is not permitted in the NestHost attribute >>> - Duplicate entries are permitted in the NestMembers array >>> - Invokeinterface use for private interface methods is permitted >>> regardless of classfile version (so no exception saying "you should >>> use invokespecial"). >>> >>> ** This had a disruptive impact on the tests as using Object and >>> Object[] as "bad hosts" now hit the "not in same package" error >>> instead of the intended error - so these had to be replaced with a >>> new class defined in the same (unnamed) package. >>> >>> All tests were updated to match the changes, and new tests added >>> where needed. In particular: >>> - nest membership tests had to add the bad "SelfHost" case >>> - reflection API getNestMembers() had to allow for and test, >>> self-reference and duplicate entries [the spec is being clarified >>> under JDK-8193408] >>> >>> Some minor cleanups: >>> - src/hotspot/share/classfile/stackMapFrame.hpp >>> ?? - reverted leftover copyright year change (file is not modified >>> from mainline version) >>> -? src/hotspot/share/classfile/verifier.cpp >>> ?? - reverted leftover layout and whitespace changes (file is not >>> modified from mainline version) >>> >>> Thanks, >>> David From david.holmes at oracle.com Tue Jan 9 05:07:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Jan 2018 15:07:41 +1000 Subject: [Nestmates] RFR: 8191114: [Nestmates] Update access control exception handling and other features per final JVMS proposal In-Reply-To: <962fd37e-33e5-e163-2c13-67690196db30@oracle.com> References: <6a881d3a-9e99-781b-3910-0afd38715d39@oracle.com> <51652ef4-5dc3-4a87-748c-b0d6e6084b6a@oracle.com> <40d4b71c-b575-0488-7813-57fe4d17886a@oracle.com> <962fd37e-33e5-e163-2c13-67690196db30@oracle.com> Message-ID: <2f87ddfd-e1ce-147d-810b-410ffeb9c1db@oracle.com> Helps if I give the link: http://cr.openjdk.java.net/~dholmes/8191114/webrev.v2/ David On 9/01/2018 2:50 PM, David Holmes wrote: > Merged with latest jdk/jdk code. The jcod files are now defined as > classfile version 55 - their final value. The nestmate logic is > currently still enabled for JDK 10+ - I will bump that to 11 once the > actual JDK version is bumped. > > I also want to clarify that these updates relate primarily to the actual > nestmate implementation. There are changes proposed in the JVMS that > affect the behaviour in cases that need not involve nestmates. Those > changes are still under discussion and any necessary implementation and > test changes will be made once those discussions are finalized. > > Also something I should have called out is the changes to the > SelectionResolution test InvokeInterfaceICCE. With the changes to allow > invokeinterface for private methods, there is one test group that no > longer fails as expected and has been removed. I've placed it in > InvokeInterfaceSuccess but it is commented out as it doesn't succeed. It > seems to be some subset of the tests in that "group" that need to be > modified but the SelectionResolution tests are not easily understood or > adapted in that way. I will file a follow up issue for this. > > I'll let this sit for a day or so before pushing. I'm not expecting > active reviews and I need to move on. > > Thanks, > David > > On 15/12/2017 6:56 PM, David Holmes wrote: >> And updated in place to merge in the classfile version 54 changes - >> all jcod files needed updating. >> >> David >> >> On 15/12/2017 5:48 PM, David Holmes wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8191114/webrev.v1/ >>> >>> Only difference is classFileParser.cpp. The nestmate attributes >>> should only be processed in a Java 10 (for now) version classfile. >>> >>> Thanks, >>> David >>> >>> On 13/12/2017 5:31 PM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191114 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8191114/webrev/ >>>> >>>> The final proposed changes to the JVMS have been discussed by the EG >>>> and it is time to bring everything into line with the proposed spec. >>>> >>>> The main changes are: >>>> - Process for determining the nest-host has changed, specifically: >>>> ?? - same package check is done first** >>>> ?? - IncompatibleClassChangeError is thrown instead of >>>> IllegalAccessError >>>> - A self-reference is permitted in the NestMembers array >>>> - A self-reference is not permitted in the NestHost attribute >>>> - Duplicate entries are permitted in the NestMembers array >>>> - Invokeinterface use for private interface methods is permitted >>>> regardless of classfile version (so no exception saying "you should >>>> use invokespecial"). >>>> >>>> ** This had a disruptive impact on the tests as using Object and >>>> Object[] as "bad hosts" now hit the "not in same package" error >>>> instead of the intended error - so these had to be replaced with a >>>> new class defined in the same (unnamed) package. >>>> >>>> All tests were updated to match the changes, and new tests added >>>> where needed. In particular: >>>> - nest membership tests had to add the bad "SelfHost" case >>>> - reflection API getNestMembers() had to allow for and test, >>>> self-reference and duplicate entries [the spec is being clarified >>>> under JDK-8193408] >>>> >>>> Some minor cleanups: >>>> - src/hotspot/share/classfile/stackMapFrame.hpp >>>> ?? - reverted leftover copyright year change (file is not modified >>>> from mainline version) >>>> -? src/hotspot/share/classfile/verifier.cpp >>>> ?? - reverted leftover layout and whitespace changes (file is not >>>> modified from mainline version) >>>> >>>> Thanks, >>>> David From david.holmes at oracle.com Thu Jan 11 04:04:35 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 11 Jan 2018 04:04:35 +0000 Subject: hg: valhalla/valhalla: 8191114: [Nestmates] Update access control exception handling and other features per final JVMS proposal Message-ID: <201801110404.w0B44ah0029938@aojmv0008.oracle.com> Changeset: b7a6437987b2 Author: dholmes Date: 2018-01-10 22:59 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b7a6437987b2 8191114: [Nestmates] Update access control exception handling and other features per final JVMS proposal Reviewed-by: dholmes ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/stackMapFrame.hpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/BadNestHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/BadNestMembersEntry.jcod ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/BadNestMembersLength.jcod ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/ConflictingAttributesInNestHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/ConflictingAttributesInNestMember.jcod - test/hotspot/jtreg/runtime/Nestmates/classFileParsing/DuplicateNestMemberEntry.jcod ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/TestNestmateAttributes.java ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/TwoNestHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/classFileParsing/TwoNestMembers.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/CallerMissingHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/CallerNoHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/CallerNotInstanceHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/CallerNotOurHost.jcod + test/hotspot/jtreg/runtime/Nestmates/membership/CallerSelfHost.jcod + test/hotspot/jtreg/runtime/Nestmates/membership/InvalidNestHost.java ! test/hotspot/jtreg/runtime/Nestmates/membership/PackagedNestHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/PackagedNestHost2Member.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/PackagedNestHostMember.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/TargetMissingHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/TargetNoHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/TargetNotInstanceHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/TargetNotOurHost.jcod + test/hotspot/jtreg/runtime/Nestmates/membership/TargetSelfHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/membership/TestNestmateMembership.java ! test/hotspot/jtreg/runtime/Nestmates/privateConstructors/ExternalSub.jcod ! test/hotspot/jtreg/runtime/Nestmates/privateConstructors/ExternalSuper.jcod ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/ExternalSub.jcod ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/ExternalSuper.jcod ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/MissingMethod.jcod ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/MissingMethodWithSuper.jcod ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/MissingNestHost.jcod - test/hotspot/jtreg/runtime/Nestmates/privateMethods/StaticIfaceError.jcod - test/hotspot/jtreg/runtime/Nestmates/privateMethods/StaticIfaceGood.jcod - test/hotspot/jtreg/runtime/Nestmates/privateMethods/TestInvokeInterface.java ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostOfMemberMalformedHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostOfMemberMissingHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostOfMemberNoHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostOfMemberNotInstanceHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostOfMemberNotOurHost.jcod + test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostWithDuplicateMembers.jcod + test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/HostWithSelfMember.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/Hosts.java + test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/InvalidNestHost.java ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/MalformedHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/MemberMalformedHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/MemberMissingHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/MemberNoHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/MemberNotInstanceHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/MemberNotOurHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/PackagedNestHost.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/PackagedNestHost2Member.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/PackagedNestHostMember.jcod ! test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/TestReflectionAPI.java ! test/hotspot/jtreg/runtime/SelectionResolution/InvokeInterfaceICCE.java ! test/hotspot/jtreg/runtime/SelectionResolution/InvokeInterfaceSuccessTest.java From david.holmes at oracle.com Thu Jan 11 08:12:29 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jan 2018 18:12:29 +1000 Subject: [Nestmates] RFR: 8194409: [Nestmates] Update cpCache and related handling for invokeinterface of private interface methods Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8194409 webrev: http://cr.openjdk.java.net/~dholmes/8194409/webrev/ When we switched to using invokeinterface, instead of invokespecial, for private interface method invocations, it all "just worked" (more or less). But it turns out that it works in relation to the interpreter and cpCache in a way that causes the logic to follow a path reserved for the extreme corner case of invokeinterface targetting a non-public method of java.lang.Object. With the fix for JDK-8154587 (not yet in valhall repo) that path will now hit an assertion failure if the target method is not from Object. So we set up a similar but specific path for private interface methods, through the cpCache logic in the TemplateTable interpreter and onto the LinkResolver. Unfortunately the TemplateTable changes are architecture specific. I have proposed fixes for each OpenJDK architecture, but can only test for x86 and sparc. I will solicit assistance to get the Aarch64, PPC64 and S390 platforms tested before any of this gets out of the valhalla repo. Thanks, David From david.simms at oracle.com Thu Jan 11 09:56:14 2018 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 11 Jan 2018 09:56:14 +0000 Subject: hg: valhalla/valhalla: 2 new changesets Message-ID: <201801110956.w0B9uFuI028491@aojmv0008.oracle.com> Changeset: 544780faedb0 Author: dsimms Date: 2018-01-11 10:45 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/544780faedb0 Merge ! make/Images.gmk ! make/autoconf/generated-configure.sh ! make/conf/jib-profiles.js - make/langtools/intellij/runConfigurations/javah.xml - make/langtools/test/bootstrap/javah.sh - make/langtools/test/lib/javah.sh ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/ci/ciField.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp - src/java.base/share/classes/java/util/ArraysSupport.java ! src/java.base/share/classes/module-info.java - src/java.base/share/native/include/classfile_constants.h + src/java.base/share/native/include/classfile_constants.h.template ! src/java.base/share/native/libjava/System.c ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java ! test/hotspot/jtreg/ProblemList.txt - test/jdk/java/net/httpclient/RequestProcessorExceptions.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: 45ac8bb4f6f5 Author: dsimms Date: 2018-01-11 10:48 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/45ac8bb4f6f5 Adjust Testing ! test/hotspot/jtreg/ProblemList.txt From david.simms at oracle.com Thu Jan 11 11:25:40 2018 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 11 Jan 2018 11:25:40 +0000 Subject: hg: valhalla/valhalla: Un-intentional merge Message-ID: <201801111125.w0BBPetj000797@aojmv0008.oracle.com> Changeset: 2f9dcd8df5d9 Author: dsimms Date: 2018-01-11 12:21 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2f9dcd8df5d9 Un-intentional merge ! make/autoconf/generated-configure.sh From david.simms at oracle.com Fri Jan 12 08:48:22 2018 From: david.simms at oracle.com (david.simms at oracle.com) Date: Fri, 12 Jan 2018 08:48:22 +0000 Subject: hg: valhalla/valhalla: Experiments on Vanilla JDK Message-ID: <201801120848.w0C8mMXG017423@aojmv0008.oracle.com> Changeset: a6c73ed70e90 Author: dsimms Date: 2018-01-11 10:15 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a6c73ed70e90 Experiments on Vanilla JDK From david.simms at oracle.com Fri Jan 12 09:15:42 2018 From: david.simms at oracle.com (David Simms) Date: Fri, 12 Jan 2018 10:15:42 +0100 Subject: [EXP] New branch "exp" to perform some experiments for LWorld proprosal Message-ID: <046bbe41-d912-2667-0193-88e7124d1158@oracle.com> A new branch, called "exp" ("experiments"), has been created in the Valhalla project repository. There are a number of performance concerns raised when thinking about the current "LWorld prototype" [1], most notably the cost of: * differentiating various types of oops pointing to objects versus values o assumption is that klass indirection is too expensive * implementing alternative byte-code behavior, e.g.: o "ifacmp*", failed value oops ptr compare, is this test itself expensive, or implicit "equals" too expensive ? The intention is to use the "exp" branch to conduct experiments on mainline JDK code, to investigate implementation costs and patterns in existing JDK and applications when considering "common cases" for compatibility and migration issues. Initial interest will be directed at JDK classes currently documented as "value-based" [2]. /D [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2017-December/003631.html [2] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/java/lang/doc-files/ValueBased.html From tobias.hartmann at oracle.com Fri Jan 12 15:29:15 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Jan 2018 16:29:15 +0100 Subject: RFR(S): 8195001: [MVT] Avoid allocations of default value types Message-ID: <18de4b45-f036-8601-7300-d40c59735aeb@oracle.com> Hi, please review the following enhancement that I had in my queue for a while: https://bugs.openjdk.java.net/browse/JDK-8195001 http://cr.openjdk.java.net/~thartmann/8195001/webrev.00/ C2 now detects default value types more reliably and aggressively removes their allocations by replacing them with the pre-allocated default oop (see test35/test36). All tests pass. Thanks, Tobias From rwestrel at redhat.com Fri Jan 12 15:59:25 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 12 Jan 2018 16:59:25 +0100 Subject: RFR(S): 8195001: [MVT] Avoid allocations of default value types In-Reply-To: <18de4b45-f036-8601-7300-d40c59735aeb@oracle.com> References: <18de4b45-f036-8601-7300-d40c59735aeb@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8195001/webrev.00/ Looks reasonable. Roland. From tobias.hartmann at oracle.com Fri Jan 12 16:50:27 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Jan 2018 17:50:27 +0100 Subject: RFR(S): 8195001: [MVT] Avoid allocations of default value types In-Reply-To: References: <18de4b45-f036-8601-7300-d40c59735aeb@oracle.com> Message-ID: <135215da-2042-52c6-dd23-16ebb89907c0@oracle.com> Thanks Roland! Best regards, Tobias On 12.01.2018 16:59, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8195001/webrev.00/ > > Looks reasonable. > > Roland. > From david.holmes at oracle.com Mon Jan 15 03:50:17 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 15 Jan 2018 03:50:17 +0000 Subject: hg: valhalla/valhalla: 8195081: [Nestmates] Revert unintentional file changes Message-ID: <201801150350.w0F3oItx024326@aojmv0008.oracle.com> Changeset: 486d1a00efa8 Author: dholmes Date: 2018-01-14 22:45 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/486d1a00efa8 8195081: [Nestmates] Revert unintentional file changes ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/oops/constantPool.cpp ! test/hotspot/jtreg/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java From david.holmes at oracle.com Mon Jan 15 03:57:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Jan 2018 13:57:02 +1000 Subject: [Nestmates] RFR: 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only Message-ID: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> Trivial update: - javac: only generate nestmate attributes and virtual invoke bytecodes for private methods, when outputting for JDK 11 / classfile version 55 - hotspot: only read nestmate attributes if classfile version >= 55 (JDK 11) bug: https://bugs.openjdk.java.net/browse/JDK-8194856 webrev: http://cr.openjdk.java.net/~dholmes/8194856/webrev/ Thanks, David ----- --- old/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 22:35:12.386673245 -0500 +++ new/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 22:35:10.230549972 -0500 @@ -3469,7 +3469,7 @@ assert(runtime_invisible_type_annotations != NULL, "null invisible type annotations"); } cfs->skip_u1(attribute_length, CHECK); - } else if (_major_version >= JAVA_10_VERSION) { + } else if (_major_version >= JAVA_11_VERSION) { if (tag == vmSymbols::tag_nest_members()) { // Check for NestMembers tag if (parsed_nest_members_attribute) { --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java 2018-01-14 22:35:19.063054956 -0500 +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java 2018-01-14 22:35:16.894930997 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -158,13 +158,13 @@ /** Does the target VM support nestmate access? */ public boolean hasNestmateAccess() { - return compareTo(JDK1_10) >= 0; + return compareTo(JDK1_11) >= 0; } /** Does the target VM support virtual private invocations? */ public boolean hasVirtualPrivateInvoke() { - return compareTo(JDK1_10) >= 0; + return compareTo(JDK1_11) >= 0; } } From tobias.hartmann at oracle.com Mon Jan 15 08:01:08 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 15 Jan 2018 08:01:08 +0000 Subject: hg: valhalla/valhalla: 8195001: [MVT] Avoid allocations of default value types Message-ID: <201801150801.w0F819gg012766@aojmv0008.oracle.com> Changeset: 1dabe69eb829 Author: thartmann Date: 2018-01-15 08:56 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1dabe69eb829 8195001: [MVT] Avoid allocations of default value types Reviewed-by: roland ! src/hotspot/share/opto/valuetypenode.cpp ! src/hotspot/share/opto/valuetypenode.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestBasicFunctionality.java From maurizio.cimadamore at oracle.com Mon Jan 15 13:15:44 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Jan 2018 13:15:44 +0000 Subject: [Nestmates] RFR: 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only In-Reply-To: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> References: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> Message-ID: Javac changes look good - thanks Maurizio On 15/01/18 03:57, David Holmes wrote: > Trivial update: > - javac: only generate nestmate attributes and virtual invoke > bytecodes for private methods, when outputting for JDK 11 / classfile > version 55 > - hotspot: only read nestmate attributes if classfile version >= 55 > (JDK 11) > > bug: https://bugs.openjdk.java.net/browse/JDK-8194856 > webrev: http://cr.openjdk.java.net/~dholmes/8194856/webrev/ > > Thanks, > David > ----- > > --- old/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 > 22:35:12.386673245 -0500 > +++ new/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 > 22:35:10.230549972 -0500 > @@ -3469,7 +3469,7 @@ > ?????????? assert(runtime_invisible_type_annotations != NULL, "null > invisible type annotations"); > ???????? } > ???????? cfs->skip_u1(attribute_length, CHECK); > -????? } else if (_major_version >= JAVA_10_VERSION) { > +????? } else if (_major_version >= JAVA_11_VERSION) { > ???????? if (tag == vmSymbols::tag_nest_members()) { > ?????????? // Check for NestMembers tag > ?????????? if (parsed_nest_members_attribute) { > --- > old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java > 2018-01-14 22:35:19.063054956 -0500 > +++ > new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java > 2018-01-14 22:35:16.894930997 -0500 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -158,13 +158,13 @@ > ???? /** Does the target VM support nestmate access? > ????? */ > ???? public boolean hasNestmateAccess() { > -??????? return compareTo(JDK1_10) >= 0; > +??????? return compareTo(JDK1_11) >= 0; > ???? } > > ???? /** Does the target VM support virtual private invocations? > ????? */ > ???? public boolean hasVirtualPrivateInvoke() { > -??????? return compareTo(JDK1_10) >= 0; > +??????? return compareTo(JDK1_11) >= 0; > ???? } > > ?} From karen.kinnear at oracle.com Mon Jan 15 14:27:30 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 15 Jan 2018 09:27:30 -0500 Subject: [Nestmates] RFR: 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only In-Reply-To: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> References: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> Message-ID: VM side looks good. Thanks David Karen > On Jan 14, 2018, at 10:57 PM, David Holmes wrote: > > Trivial update: > - javac: only generate nestmate attributes and virtual invoke bytecodes for private methods, when outputting for JDK 11 / classfile version 55 > - hotspot: only read nestmate attributes if classfile version >= 55 (JDK 11) > > bug: https://bugs.openjdk.java.net/browse/JDK-8194856 > webrev: http://cr.openjdk.java.net/~dholmes/8194856/webrev/ > > Thanks, > David > ----- > > --- old/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 22:35:12.386673245 -0500 > +++ new/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 22:35:10.230549972 -0500 > @@ -3469,7 +3469,7 @@ > assert(runtime_invisible_type_annotations != NULL, "null invisible type annotations"); > } > cfs->skip_u1(attribute_length, CHECK); > - } else if (_major_version >= JAVA_10_VERSION) { > + } else if (_major_version >= JAVA_11_VERSION) { > if (tag == vmSymbols::tag_nest_members()) { > // Check for NestMembers tag > if (parsed_nest_members_attribute) { > --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java 2018-01-14 22:35:19.063054956 -0500 > +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java 2018-01-14 22:35:16.894930997 -0500 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -158,13 +158,13 @@ > /** Does the target VM support nestmate access? > */ > public boolean hasNestmateAccess() { > - return compareTo(JDK1_10) >= 0; > + return compareTo(JDK1_11) >= 0; > } > > /** Does the target VM support virtual private invocations? > */ > public boolean hasVirtualPrivateInvoke() { > - return compareTo(JDK1_10) >= 0; > + return compareTo(JDK1_11) >= 0; > } > > } From david.holmes at oracle.com Mon Jan 15 21:20:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jan 2018 07:20:43 +1000 Subject: [Nestmates] RFR: 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only In-Reply-To: References: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> Message-ID: Thanks Maurizio. David On 15/01/2018 11:15 PM, Maurizio Cimadamore wrote: > Javac changes look good - thanks > > Maurizio > > > On 15/01/18 03:57, David Holmes wrote: >> Trivial update: >> - javac: only generate nestmate attributes and virtual invoke >> bytecodes for private methods, when outputting for JDK 11 / classfile >> version 55 >> - hotspot: only read nestmate attributes if classfile version >= 55 >> (JDK 11) >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8194856 >> webrev: http://cr.openjdk.java.net/~dholmes/8194856/webrev/ >> >> Thanks, >> David >> ----- >> >> --- old/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 >> 22:35:12.386673245 -0500 >> +++ new/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 >> 22:35:10.230549972 -0500 >> @@ -3469,7 +3469,7 @@ >> ?????????? assert(runtime_invisible_type_annotations != NULL, "null >> invisible type annotations"); >> ???????? } >> ???????? cfs->skip_u1(attribute_length, CHECK); >> -????? } else if (_major_version >= JAVA_10_VERSION) { >> +????? } else if (_major_version >= JAVA_11_VERSION) { >> ???????? if (tag == vmSymbols::tag_nest_members()) { >> ?????????? // Check for NestMembers tag >> ?????????? if (parsed_nest_members_attribute) { >> --- >> old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java >> 2018-01-14 22:35:19.063054956 -0500 >> +++ >> new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java >> 2018-01-14 22:35:16.894930997 -0500 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights >> reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -158,13 +158,13 @@ >> ???? /** Does the target VM support nestmate access? >> ????? */ >> ???? public boolean hasNestmateAccess() { >> -??????? return compareTo(JDK1_10) >= 0; >> +??????? return compareTo(JDK1_11) >= 0; >> ???? } >> >> ???? /** Does the target VM support virtual private invocations? >> ????? */ >> ???? public boolean hasVirtualPrivateInvoke() { >> -??????? return compareTo(JDK1_10) >= 0; >> +??????? return compareTo(JDK1_11) >= 0; >> ???? } >> >> ?} > From david.holmes at oracle.com Mon Jan 15 21:20:56 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jan 2018 07:20:56 +1000 Subject: [Nestmates] RFR: 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only In-Reply-To: References: <4c375780-dd86-37d0-43e8-623b74af3278@oracle.com> Message-ID: <0adcaa9c-0dda-3bbe-d0b4-fd4a33720d6b@oracle.com> Thanks Karen. David On 16/01/2018 12:27 AM, Karen Kinnear wrote: > > VM side looks good. Thanks David > > Karen > >> On Jan 14, 2018, at 10:57 PM, David Holmes wrote: >> >> Trivial update: >> - javac: only generate nestmate attributes and virtual invoke bytecodes for private methods, when outputting for JDK 11 / classfile version 55 >> - hotspot: only read nestmate attributes if classfile version >= 55 (JDK 11) >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8194856 >> webrev: http://cr.openjdk.java.net/~dholmes/8194856/webrev/ >> >> Thanks, >> David >> ----- >> >> --- old/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 22:35:12.386673245 -0500 >> +++ new/src/hotspot/share/classfile/classFileParser.cpp 2018-01-14 22:35:10.230549972 -0500 >> @@ -3469,7 +3469,7 @@ >> assert(runtime_invisible_type_annotations != NULL, "null invisible type annotations"); >> } >> cfs->skip_u1(attribute_length, CHECK); >> - } else if (_major_version >= JAVA_10_VERSION) { >> + } else if (_major_version >= JAVA_11_VERSION) { >> if (tag == vmSymbols::tag_nest_members()) { >> // Check for NestMembers tag >> if (parsed_nest_members_attribute) { >> --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java 2018-01-14 22:35:19.063054956 -0500 >> +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java 2018-01-14 22:35:16.894930997 -0500 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -158,13 +158,13 @@ >> /** Does the target VM support nestmate access? >> */ >> public boolean hasNestmateAccess() { >> - return compareTo(JDK1_10) >= 0; >> + return compareTo(JDK1_11) >= 0; >> } >> >> /** Does the target VM support virtual private invocations? >> */ >> public boolean hasVirtualPrivateInvoke() { >> - return compareTo(JDK1_10) >= 0; >> + return compareTo(JDK1_11) >= 0; >> } >> >> } > From david.holmes at oracle.com Tue Jan 16 01:23:33 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 16 Jan 2018 01:23:33 +0000 Subject: hg: valhalla/valhalla: 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only Message-ID: <201801160123.w0G1NY4P004858@aojmv0008.oracle.com> Changeset: 8a4d11b836d4 Author: dholmes Date: 2018-01-15 20:18 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8a4d11b836d4 8194856: [Nestmates] Activate nestmate processing for JDK Version 11 only Reviewed-by: acorn, mcimadamore ! src/hotspot/share/classfile/classFileParser.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java From frederic.parain at oracle.com Tue Jan 16 20:56:11 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 16 Jan 2018 15:56:11 -0500 Subject: Moving from VVT to the L-world value types (LWVT) Message-ID: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object is the top type of all value classes (as discussed during the November meetings in Burlington). This proposal tries to evolve the JVMS with a small set of changes to have an implementable specification of the L-world. Instead of trying to add Q/R/U-types to the JVMS, the approach is to expend the JVMS notion of ?reference? to cover both regular classes and value classes. The notion of ?class? has also be extended to cover both, but when needed, it is possible to specify an ?object class? or a ?value class?, or respectively, ?an instance of an object class? vs ?an instance of a value class?. The ?Q?;? format is still used for value class types, but the ?;Q? trick is gone. The attach document contains sections of the JVMS that have been modified to implement the L-world. The text doesn?t have change bars, so people are encouraged to read each modified section entirely to see if it is consistent to cover all cases of the L-world. Here?s a quick summary of the changes with some consequences on the HotSpot code: - all v-bytecodes are removed except vdefault and vwithfield - all bytecodes operating on an object receiver are updated to support values as well, except putfield and new - single carrier type for both instances of object classes and instances of value classes - this carrier type maps to the T_OBJECT BasicType - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) - qtos TosState is removed - JNI: the jobject type can be used to carry either a reference to an object or an array or a value. The type jvaluetype, sub-type of jobject, is used when only a value class instance is expected - Q?; remains the way to encode value classes in signature (fields and methods) - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a symbolic reference to either an object class or a value class - the ;Q escape sequence is not used anymore in value class names One important point of this exercise is to ensure that the migration of Value Based Classes into Value Classes is possible, and doable with a reasonable complexity and costs. In addition to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals on how to deal with the VBC migration. Migration of Value Based Classes into Value Classes: - challenges: - signature mismatch - null - change in behavior - proposal for signature mismatch: - with LWVT, value class types in signatures are using the Q?; format - legacy code is using signature with L?; format (because VBC are object classes) - methods will have two signatures: - true signature, which could include Q?; elements - a L-ified signature where all Q?; elements are re-written with the L?; format - method lookup still works by signature string comparisons - the signature of the method being looked up will compared against both the true and the L-ified signatures, if the looked up signature matches the L-ified signature but not the true signature, it means a situation where legacy code is trying to invoke migrated code has been detected, and additional work might be required for the invocation (actions to be taken have to be defined) - signature mismatch can also occur for fields, this is still being investigating, the proposal will be updated as soon as we have a solution ready to be published - proposal for null references leaking to migrated code - having a null reference for a Value Based Class variable or field is valid in legacy code but it becomes invalid when the Value Based Class has been migrated to a Value Class - trying to prevent all references with a value class type to get a null value would be very expensive (it would require to look at the stackmap for each assignment to a local variable) - the proposed solution is to allow null references for local variable and expression stack slots, but forbid them for fields or array elements (bytecodes operating on fields and array have to be updated to throw a NPE whenever a null reference is provided instead of a value class instance) - null references are likely to be an issue for JIT optimizations like passing values in registers when a method is invoked. The proposed solution is to only allow null references for value classes in legacy code, by detecting them and blocking them when leaking to migrated code. The detection can be done at invocation time, when a mismatch between the signature expected by the caller and the real signature of the callee is detected (see signature mismatch proposal above) - the null reference should also be detected and blocked when it is used as a return value and the type of the value to be returned is a value class type In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories in the chart are not very precise, but we can use it as a starting point for our discussions. The chart can also help defining which experiments could be done to estimate the costs of the different additional checks needed to be added to existing bytecodes. All these are preliminary works for a proposal to implement the L-world value types and not a definitive specification. This has to be analyzed and discussed before any attempt to implement it starts. Feel free to send feedback, comments, other proposals, etc. Thank you, Fred -------------- next part -------------- From frederic.parain at oracle.com Tue Jan 16 21:27:05 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 16 Jan 2018 16:27:05 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: <984FE1BA-33C1-41AA-8ABB-C20094784AA5@oracle.com> It seems attachments have been stripped. Trying to re-send them one by one. Here?s the JVMS update. Fred From frederic.parain at oracle.com Tue Jan 16 21:29:07 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 16 Jan 2018 16:29:07 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <984FE1BA-33C1-41AA-8ABB-C20094784AA5@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <984FE1BA-33C1-41AA-8ABB-C20094784AA5@oracle.com> Message-ID: <83CB6F3E-5FE1-4901-AD8A-02142F4745E2@oracle.com> Here?s the chart. Fred From john.r.rose at oracle.com Tue Jan 16 21:35:46 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 16 Jan 2018 13:35:46 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <984FE1BA-33C1-41AA-8ABB-C20094784AA5@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <984FE1BA-33C1-41AA-8ABB-C20094784AA5@oracle.com> Message-ID: <2556646A-1ACE-41B1-BEFE-EEEA5F3E39AE@oracle.com> On Jan 16, 2018, at 1:27 PM, Frederic Parain wrote: > > It seems attachments have been stripped. > Trying to re-send them one by one. Usually I put charts on my cr.ojn page and send a link. It's annoying, but it works. From frederic.parain at oracle.com Tue Jan 16 21:36:31 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 16 Jan 2018 16:36:31 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <2556646A-1ACE-41B1-BEFE-EEEA5F3E39AE@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <984FE1BA-33C1-41AA-8ABB-C20094784AA5@oracle.com> <2556646A-1ACE-41B1-BEFE-EEEA5F3E39AE@oracle.com> Message-ID: <3BA45E77-7C64-45DF-8433-0A283D372942@oracle.com> Thank you for the trick. I?ll do that. Fred > On Jan 16, 2018, at 16:35, John Rose wrote: > > On Jan 16, 2018, at 1:27 PM, Frederic Parain wrote: >> >> It seems attachments have been stripped. >> Trying to re-send them one by one. > > Usually I put charts on my cr.ojn page and send a link. > It's annoying, but it works. > From frederic.parain at oracle.com Tue Jan 16 21:40:40 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 16 Jan 2018 16:40:40 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: <4AA26926-C11B-4D21-9FFA-5B0C210F7349@oracle.com> Documents were stripped by the mail server. They can be downloaded from this directory: http://cr.openjdk.java.net/~fparain/L-world/ Sorry for the inconvenience. Fred > On Jan 16, 2018, at 15:56, Frederic Parain wrote: > > Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object > is the top type of all value classes (as discussed during the November meetings > in Burlington). > > This proposal tries to evolve the JVMS with a small set of changes to have an > implementable specification of the L-world. Instead of trying to add Q/R/U-types to > the JVMS, the approach is to expend the JVMS notion of ?reference? to cover > both regular classes and value classes. The notion of ?class? has also be extended > to cover both, but when needed, it is possible to specify an ?object class? or a > ?value class?, or respectively, ?an instance of an object class? vs ?an instance of > a value class?. The ?Q?;? format is still used for value class types, but the ?;Q? > trick is gone. > > The attach document contains sections of the JVMS that have been modified > to implement the L-world. The text doesn?t have change bars, so people are > encouraged to read each modified section entirely to see if it is consistent to > cover all cases of the L-world. > > > Here?s a quick summary of the changes with some consequences on the HotSpot code: > - all v-bytecodes are removed except vdefault and vwithfield > - all bytecodes operating on an object receiver are updated to support values as well, > except putfield and new > - single carrier type for both instances of object classes and instances of value classes > - this carrier type maps to the T_OBJECT BasicType > - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) > - qtos TosState is removed > - JNI: the jobject type can be used to carry either a reference to an object or an > array or a value. The type jvaluetype, sub-type of jobject, is used when only > a value class instance is expected > - Q?; remains the way to encode value classes in signature (fields and methods) > - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a > symbolic reference to either an object class or a value class > - the ;Q escape sequence is not used anymore in value class names > > > One important point of this exercise is to ensure that the migration of Value Based Classes > into Value Classes is possible, and doable with a reasonable complexity and costs. In addition > to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals > on how to deal with the VBC migration. > > > Migration of Value Based Classes into Value Classes: > - challenges: > - signature mismatch > - null > - change in behavior > > - proposal for signature mismatch: > - with LWVT, value class types in signatures are using the Q?; format > - legacy code is using signature with L?; format (because VBC are object classes) > - methods will have two signatures: > - true signature, which could include Q?; elements > - a L-ified signature where all Q?; elements are re-written with the L?; format > - method lookup still works by signature string comparisons > - the signature of the method being looked up will compared against both the > true and the L-ified signatures, if the looked up signature matches the L-ified > signature but not the true signature, it means a situation where legacy code > is trying to invoke migrated code has been detected, and additional work might > be required for the invocation (actions to be taken have to be defined) > - signature mismatch can also occur for fields, this is still being investigating, the > proposal will be updated as soon as we have a solution ready to be published > > - proposal for null references leaking to migrated code > - having a null reference for a Value Based Class variable or field is valid in legacy code > but it becomes invalid when the Value Based Class has been migrated to a Value Class > - trying to prevent all references with a value class type to get a null value would be very > expensive (it would require to look at the stackmap for each assignment to a local variable) > - the proposed solution is to allow null references for local variable and expression stack slots, > but forbid them for fields or array elements (bytecodes operating on fields and array have to > be updated to throw a NPE whenever a null reference is provided instead of a value class > instance) > - null references are likely to be an issue for JIT optimizations like passing values in registers > when a method is invoked. The proposed solution is to only allow null references for value classes > in legacy code, by detecting them and blocking them when leaking to migrated code. The > detection can be done at invocation time, when a mismatch between the signature expected > by the caller and the real signature of the callee is detected (see signature mismatch proposal above) > - the null reference should also be detected and blocked when it is used as a return value and the > type of the value to be returned is a value class type > > > In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to > be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories > in the chart are not very precise, but we can use it as a starting point for our discussions. The chart > can also help defining which experiments could be done to estimate the costs of the different additional > checks needed to be added to existing bytecodes. > > All these are preliminary works for a proposal to implement the L-world value types and not a definitive > specification. This has to be analyzed and discussed before any attempt to implement it starts. > Feel free to send feedback, comments, other proposals, etc. > > Thank you, > > Fred > > From david.holmes at oracle.com Wed Jan 17 04:44:49 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 17 Jan 2018 04:44:49 +0000 Subject: hg: valhalla/valhalla: 8194409: [Nestmates] Update cpCache and related handling for invokeinterface of private interface methods Message-ID: <201801170444.w0H4inCb006081@aojmv0008.oracle.com> Changeset: 5b16fab6ac7f Author: dholmes Date: 2018-01-16 23:40 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5b16fab6ac7f 8194409: [Nestmates] Update cpCache and related handling for invokeinterface of private interface methods Reviewed-by: dholmes ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/sparc/templateTable_sparc.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/cpCache.cpp From david.simms at oracle.com Wed Jan 17 12:26:33 2018 From: david.simms at oracle.com (David Simms) Date: Wed, 17 Jan 2018 13:26:33 +0100 Subject: [Exp] Experimenting with "value-based" classes and oop testing Message-ID: So to lay some ground-work for testing value oops versus reference oops, I've created the following patch "Value based classes" (VBC) for the experimental branch (exp): http://cr.openjdk.java.net/~dsimms/valhalla/exp_vbc/webrev0/ Highlights: * Added "INCLUDE_VBC" feature macro to clearly identify "Value-based class" feature * klass.hpp:572 Klass may be marked as "value-based" via a new access flag o systemDictionary.cpp:2053 uses the flag "ValueBasedClasses" to mark the current JDK value-based classes, or the user may specify their own * Prototype of efficient "oopDesc::klass_is_value_based()" test has been implemented by encoding "odd/even" klass ptr into the "oop._metadata" (i.e. oop klass ptr) o klass.cpp:174 affectively double the klass ptr alignment (from 8 to 16 bytes), and ensures value classes are aligned "odd" (or to 8 bytes), and regular classes to 16 bytes o Wastes a little memory, but given that instanceKlass weigh around 460 bytes, an extra 8 bytes seemed like a small price... o ...testing for value classes simply involves test the effective least significant bit in the oop metadata field, should work for both compressed (lsbit) and uncompress klass ptr (is 8 byte aligned). + klass.inline.hpp:74 should be relatively simple to implement in both JIT and template assembler One can use this as basis for building experiments with alternative behaviour for L-World proposal, e.g. monitor operations involving values. Comments ? From forax at univ-mlv.fr Thu Jan 18 16:09:11 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 18 Jan 2018 17:09:11 +0100 (CET) Subject: [Exp] Experimenting with "value-based" classes and oop testing In-Reply-To: References: Message-ID: <1505025090.1788134.1516291751034.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Simms" > ?: "valhalla-dev" > Envoy?: Mercredi 17 Janvier 2018 13:26:33 > Objet: [Exp] Experimenting with "value-based" classes and oop testing > So to lay some ground-work for testing value oops versus reference oops, > I've created the following patch "Value based classes" (VBC) for the > experimental branch (exp): > > http://cr.openjdk.java.net/~dsimms/valhalla/exp_vbc/webrev0/ > > Highlights: > > * Added "INCLUDE_VBC" feature macro to clearly identify "Value-based > class" feature > * klass.hpp:572 Klass may be marked as "value-based" via a new access flag > o systemDictionary.cpp:2053 uses the flag "ValueBasedClasses" to > mark the current JDK value-based classes, or the user may > specify their own > * Prototype of efficient "oopDesc::klass_is_value_based()" test has > been implemented by encoding "odd/even" klass ptr into the > "oop._metadata" (i.e. oop klass ptr) > o klass.cpp:174 affectively double the klass ptr alignment (from 8 > to 16 bytes), and ensures value classes are aligned "odd" (or to > 8 bytes), and regular classes to 16 bytes > o Wastes a little memory, but given that instanceKlass weigh > around 460 bytes, an extra 8 bytes seemed like a small price... > o ...testing for value classes simply involves test the effective > least significant bit in the oop metadata field, should work for > both compressed (lsbit) and uncompress klass ptr (is 8 byte > aligned). > + klass.inline.hpp:74 should be relatively simple to implement > in both JIT and template assembler > > One can use this as basis for building experiments with alternative > behaviour for L-World proposal, e.g. monitor operations involving values. > > Comments ? clever trick, in the test, because you do not use LocalDateTime, @run can be simplified to @run testng/othervm -XX:ValueBasedClasses=java/time/LocalTime,ValueBased ValueBased my other question is what is the purpose to have a value based class with mutable fields ? R?mi From david.simms at oracle.com Fri Jan 19 08:25:21 2018 From: david.simms at oracle.com (David Simms) Date: Fri, 19 Jan 2018 09:25:21 +0100 Subject: [Exp] Experimenting with "value-based" classes and oop testing In-Reply-To: <1505025090.1788134.1516291751034.JavaMail.zimbra@u-pem.fr> References: <1505025090.1788134.1516291751034.JavaMail.zimbra@u-pem.fr> Message-ID: <79d07633-7f59-db6c-b95c-22703c1b6d08@oracle.com> On 18/01/18 17:09, Remi Forax wrote: > ----- Mail original ----- >> De: "David Simms" >> ?: "valhalla-dev" >> Envoy?: Mercredi 17 Janvier 2018 13:26:33 >> Objet: [Exp] Experimenting with "value-based" classes and oop testing >> So to lay some ground-work for testing value oops versus reference oops, >> I've created the following patch "Value based classes" (VBC) for the >> experimental branch (exp): >> >> http://cr.openjdk.java.net/~dsimms/valhalla/exp_vbc/webrev0/ >> >> Highlights: >> >> * Added "INCLUDE_VBC" feature macro to clearly identify "Value-based >> class" feature >> * klass.hpp:572 Klass may be marked as "value-based" via a new access flag >> o systemDictionary.cpp:2053 uses the flag "ValueBasedClasses" to >> mark the current JDK value-based classes, or the user may >> specify their own >> * Prototype of efficient "oopDesc::klass_is_value_based()" test has >> been implemented by encoding "odd/even" klass ptr into the >> "oop._metadata" (i.e. oop klass ptr) >> o klass.cpp:174 affectively double the klass ptr alignment (from 8 >> to 16 bytes), and ensures value classes are aligned "odd" (or to >> 8 bytes), and regular classes to 16 bytes >> o Wastes a little memory, but given that instanceKlass weigh >> around 460 bytes, an extra 8 bytes seemed like a small price... >> o ...testing for value classes simply involves test the effective >> least significant bit in the oop metadata field, should work for >> both compressed (lsbit) and uncompress klass ptr (is 8 byte >> aligned). >> + klass.inline.hpp:74 should be relatively simple to implement >> in both JIT and template assembler >> >> One can use this as basis for building experiments with alternative >> behaviour for L-World proposal, e.g. monitor operations involving values. >> >> Comments ? > clever trick, > > in the test, because you do not use LocalDateTime, @run can be simplified to > @run testng/othervm -XX:ValueBasedClasses=java/time/LocalTime,ValueBased ValueBased Yeah, this test was resurrected from a previous experiment and then gutted. I should add further features using oop->klass_is_value_based() so the test actually does something useful. > > my other question is what is the purpose to have a value based class with mutable fields ? > > R?mi Hehe, yeah ValueBased test itself doesn't follow the rules, will adjust. Also thinking of adding some form of auto-value classification to class file parser, identify value type candidates in existing benchmarks, so we can see L-World costs /D From forax at univ-mlv.fr Fri Jan 19 21:10:39 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 19 Jan 2018 22:10:39 +0100 (CET) Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: <1471296970.2354395.1516396239352.JavaMail.zimbra@u-pem.fr> I think there is an alternative encoding for Q types which is worth to consider, see below ... ----- Mail original ----- > De: "Frederic Parain" > ?: "valhalla-dev" > Envoy?: Mardi 16 Janvier 2018 21:56:11 > Objet: Moving from VVT to the L-world value types (LWVT) > Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object > is the top type of all value classes (as discussed during the November meetings > in Burlington). > > This proposal tries to evolve the JVMS with a small set of changes to have an > implementable specification of the L-world. Instead of trying to add Q/R/U-types > to > the JVMS, the approach is to expend the JVMS notion of ?reference? to cover > both regular classes and value classes. The notion of ?class? has also be > extended > to cover both, but when needed, it is possible to specify an ?object class? or a > ?value class?, or respectively, ?an instance of an object class? vs ?an instance > of > a value class?. The ?Q?;? format is still used for value class types, but the > ?;Q? > trick is gone. The VM needs to know if a class is a value type or no at the time we compile something. Q-type is a way to encode that be that's not the only way. > > The attach document contains sections of the JVMS that have been modified > to implement the L-world. The text doesn?t have change bars, so people are > encouraged to read each modified section entirely to see if it is consistent to > cover all cases of the L-world. > > > Here?s a quick summary of the changes with some consequences on the HotSpot > code: > - all v-bytecodes are removed except vdefault and vwithfield > - all bytecodes operating on an object receiver are updated to support values as > well, > except putfield and new > - single carrier type for both instances of object classes and instances of > value classes > - this carrier type maps to the T_OBJECT BasicType > - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) > - qtos TosState is removed > - JNI: the jobject type can be used to carry either a reference to an object or > an > array or a value. The type jvaluetype, sub-type of jobject, is used when only > a value class instance is expected > - Q?; remains the way to encode value classes in signature (fields and methods) > - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a > symbolic reference to either an object class or a value class > - the ;Q escape sequence is not used anymore in value class names agree, let's remove ;Q encoding, it was a hack. > > > One important point of this exercise is to ensure that the migration of Value > Based Classes > into Value Classes is possible, and doable with a reasonable complexity and > costs. In addition > to the JVMS update (and consistent with the JVMS modifications), here?s a set of > proposals > on how to deal with the VBC migration. > > > Migration of Value Based Classes into Value Classes: > - challenges: > - signature mismatch > - null > - change in behavior - several classes are compiled at different times so some are using a value as a value type while some others are using a value as a reference type so we have a problem close to the separate compilation problem. > > - proposal for signature mismatch: > - with LWVT, value class types in signatures are using the Q?; format > - legacy code is using signature with L?; format (because VBC are object > classes) > - methods will have two signatures: > - true signature, which could include Q?; elements > - a L-ified signature where all Q?; elements are re-written with the L?; format > - method lookup still works by signature string comparisons > - the signature of the method being looked up will compared against both the > true and the L-ified signatures, if the looked up signature matches the L-ified > signature but not the true signature, it means a situation where legacy code > is trying to invoke migrated code has been detected, and additional work might > be required for the invocation (actions to be taken have to be defined) > - signature mismatch can also occur for fields, this is still being > investigating, the > proposal will be updated as soon as we have a solution ready to be published legacy code => legacy classes, each of them at a different states, so you will end up with more than two signatures. suppose you have two classes V and W that will becomes value types, but they are from different module managed by different companies, you can have 3 classes like this class A { LW; m(LV;) } class B extends A { LW; m(LV;) } class C extends B { LW; m(LV;) } then you migrate B to declare V as a value type class B extends A { LW; m(QV;) } then you migrate A to declare W as a value type class A { QW; m(LV;) } here, there are more than two true signatures. Let's take a step back, in Java (the language), we have already introduced features like generics or varargs that behave the same way, the only difference here is that this is something that the VM has to deal with and not something the java compiler has to deal with. How varargs works in the java compiler, it's easy, the method descriptor is an array, and the access modifier say if its a varargs or not, i think we should encode Q-type the same way. As i said, for a class, we want to know at the time this class was compiled, which types used by this class is a value type. So i propose to introduce a new class attribute named ValueTypes that contains the set of all value types that are used by that class, so for the VM a type is by default a reference type (a L-type) apart if the type is listed in the attribute ValueTypes, in that case it's a value type. Basically, having a bit for each type at class level that say if a type behave as a value type or not when the class was compiled. In term of implementation, - method only have one descriptor using L types - the verifier reject code that store null, use synchonize, etc with a type which is listed in the class attribute ValueTypes. - at runtime, the VM check that when loading a class listed in the attribute ValueTypes is a value type. - when creating the object layout of a class, field of a type listed in ValueType may be flattened - when creating an array of a type listed in ValueType may be flattened. - when calling a method or accessing a field, after resolution, the interpreter may do adaptation in order to buffer (value type -> ref) or nullcheck (ref -> value type). > > - proposal for null references leaking to migrated code > - having a null reference for a Value Based Class variable or field is valid in > legacy code > but it becomes invalid when the Value Based Class has been migrated to a Value > Class > - trying to prevent all references with a value class type to get a null value > would be very > expensive (it would require to look at the stackmap for each assignment to a > local variable) > - the proposed solution is to allow null references for local variable and > expression stack slots, > but forbid them for fields or array elements (bytecodes operating on fields and > array have to > be updated to throw a NPE whenever a null reference is provided instead of a > value class > instance) > - null references are likely to be an issue for JIT optimizations like passing > values in registers > when a method is invoked. The proposed solution is to only allow null references > for value classes > in legacy code, by detecting them and blocking them when leaking to migrated > code. The > detection can be done at invocation time, when a mismatch between the signature > expected > by the caller and the real signature of the callee is detected (see signature > mismatch proposal above) > - the null reference should also be detected and blocked when it is used as a > return value and the > type of the value to be returned is a value class type I believe what i'm proposing above match all these points. > > > In addition to the JVMS update, here?s a chart trying to summarize the new > checks that will have to > be added to existing bytecode when moving the vbytecodes semantic in to a* > bytecodes. The categories > in the chart are not very precise, but we can use it as a starting point for our > discussions. The chart > can also help defining which experiments could be done to estimate the costs of > the different additional > checks needed to be added to existing bytecodes. > > All these are preliminary works for a proposal to implement the L-world value > types and not a definitive > specification. This has to be analyzed and discussed before any attempt to > implement it starts. > Feel free to send feedback, comments, other proposals, etc. > > Thank you, > > Fred R?mi From john.r.rose at oracle.com Fri Jan 19 22:00:36 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 19 Jan 2018 14:00:36 -0800 Subject: [Exp] Experimenting with "value-based" classes and oop testing In-Reply-To: <79d07633-7f59-db6c-b95c-22703c1b6d08@oracle.com> References: <1505025090.1788134.1516291751034.JavaMail.zimbra@u-pem.fr> <79d07633-7f59-db6c-b95c-22703c1b6d08@oracle.com> Message-ID: <747A09D3-511F-4DEE-9E58-C99F748E115D@oracle.com> +100 to this experiment; as a whole it's the right thing to try. It might give us the fast acmp hack we need for L-world. A couple of comments: > On Jan 19, 2018, at 12:25 AM, David Simms wrote: >> >> >> my other question is what is the purpose to have a value based class with mutable fields ? >> >> R?mi > > Hehe, yeah ValueBased test itself doesn't follow the rules, will adjust. > > Also thinking of adding some form of auto-value classification to class file parser, identify value type candidates in existing benchmarks, so we can see L-World costs Another way to slice it would be to have a classfile scanner which spits out the names of value-able candidate classes. That could be eyeballed and then plugged into -XX:ValueBasedClasses=? I'll bet it could be hacked up in an afternoon in ASM. Remi? About mutable immutables, there is actually something worth saying: We sometimes think about designing a _larval typestate_ for immutables (of both object and value types) which would be mutable. It would be a private container for field values. Once it is loaded, it get promoted to the publishable _adult typestate_. See [1]. We would need to figure out rules for keeping the typestates separate, so that larval objects are not accidentally published (leading to races) and so that adult objects are not accidentally mutated as if they were still under construction. That last requirement is best solved, I claim, by introducing a mechanism for single-thread confinement, enforced by the JVM. These ideas are worth mulling over from time to time, as a better way to organize immutables than the standard technique of manually written builder objects like StringBuilder (and various collection builders). Anyway, if a value type has a larval object state, its fields *would* be writable, but in that state *only*. Of course, as it pupates to the adult state it would shed its object identity as well as its mutability. If it were a true object class it would shed only its mutability. It might *change* its identity, as in the case of StringBuilder.toString. Note that a StringBuilder *does* change identity when promoting to the "adult" String. Maybe we can do something about typestate with template classes?if a template could expand to both objects and value species! ? John [1] https://blogs.oracle.com/jrose/larval-objects-in-the-vm From john.r.rose at oracle.com Sat Jan 20 04:01:58 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 19 Jan 2018 20:01:58 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <1471296970.2354395.1516396239352.JavaMail.zimbra@u-pem.fr> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <1471296970.2354395.1516396239352.JavaMail.zimbra@u-pem.fr> Message-ID: On Jan 19, 2018, at 1:10 PM, Remi Forax wrote: > > So i propose to introduce a new class attribute named ValueTypes that contains the set of all value types that are used by that class, > so for the VM a type is by default a reference type (a L-type) apart if the type is listed in the attribute ValueTypes, in that case it's a value type. > Basically, having a bit for each type at class level that say if a type behave as a value type or not when the class was compiled. This is a nice idea. I hope we don't need it! I'll explain. I agree about the basic problem with Q-descriptors. In L-world, there are relatively few places where the Q/R distinction matters (and recall that U=L in L-world). So remaining uses of Q-descriptors can be viewed as places where we haven't yet figured out a different way to express the Q/R distinction, in a place where it matters. For fields, a Q-descriptor can be replaced by a normal L-descriptor, but with an ACC_VALUE bit in the field. The same ACC_VALUE bit makes sense on a class as a whole, I think. Your ValueTypes table potentially gives a different way to record ACC_VALUE bits, by associating them with (the local views of) names rather than schema elements. > In term of implementation, > - method only have one descriptor using L types For methods, a Q-descriptor has less utility. It encodes a different posture towards certain edge cases, such as the acceptance of null. But there are other ways to manage such edge cases. (For null, it can be a suitable NPE, akin to what happens today when you cast a null to int.) I don't really buy claims that method descriptors are needed to distinguish by-reference from by-value argument passing. Yes, there is a "real calling sequence" for a type like Complex, probably involving xmm registers, but the interpreter does not (cannot) know about this, and needs to use the uniform L-type as one size that fits everything. This does leave open the problem of saying when the interpreter uses the pointer copying vs. rebuffering on return instructions. To my mind that is similar to the acmp problem: You need to quickly decide whether the L-world thingy needs rebuffering or not. In all cases you can decide whether the thingy is a value simply by examining the payload of the L carrier type. If it's null, it's a reference; if it's not, we look at its class (or perhaps a tag bit or range check) to see if it needs special value processing. As long as we can avoid doing this frequently, or optimize it well when it is done frequently, the extra Q/R checks will be in the noise. > - the verifier reject code that store null, use synchonize, etc with a type which is listed in the class attribute ValueTypes. The verifier doesn't track nulls, so this proposal doesn't make sense unless nullability is added to the verifier type system. I don't think that is needed. The Java way is to assume non-nullness and back that up with a runtime check, and NPE if it fails. Same point for sync. And for acmp. The verifier has nothing to add here. The verifier has a strategic weakness: It does not load classes (with a very few exceptions, carefully minimized). It operates mostly on descriptors kinds (carrier types). (Yes it loads classes to determine sub/super relations as required by control flow. I think of that as a weakness in the design, not a feature to repeat.) Your proposal of a ValueTypes table works around this limitation by providing a local (and approximate) view fo the contents of other files (specifically, the ACC_VALUE bits). Like I said, it's clever, but I hope we don't need it. > - at runtime, the VM check that when loading a class listed in the attribute ValueTypes is a value type. The simple way to do this would seem to require a wave of recursive loading, just to check value-type bits. We try to avoid that sort of thing. (It's why the verifier is so weak.) If we adopted your proposal, we'd probably want to do a feature like class loader constraints, where classes that claim X is a value register that claim, and when X eventually loads it fails if the prediction was false. (This is one big reason I don't want to adopt your proposal, but rather sneak around it. I think method signatures mention too many types to load them all, and I don't want to manage constraints either.) Note that the issue of constraints does not appear with field descriptors, because mentioning a value field *does* require an immediate load of the field's class, and the constraint is checked immediately when the class loader is calculating the memory layout of the new class. > - when creating the object layout of a class, field of a type listed in ValueType may be flattened That can be handled by an ACC_VALUE bit on the field. > - when creating an array of a type listed in ValueType may be flattened. That can be handled by querying the metadata of the array component type. Loading an array type always forces a load of its component type. > - when calling a method or accessing a field, after resolution, the interpreter may do adaptation in order to buffer (value type -> ref) or nullcheck (ref -> value type). Yes, *that* is the key trick. This allows out-of-date clients to use nulls freely. The resulting NPEs are an artifact of the client's need to recompile, just as CCEs are an artifact of generic code that needs recompilation. They are just as rare and only-in-principle annoying. I'm sure we haven't exhausted the list of places where in L-world we still want to reach for Q-descriptors, but I think we *can* drive that list down to the empty list, without a ValueTypes table and/or special descriptors. ? John From john.r.rose at oracle.com Sat Jan 20 04:22:46 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 19 Jan 2018 20:22:46 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: > > Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object > is the top type of all value classes (as discussed during the November meetings > in Burlington). This is excellent work, Frederic; thank you. I'm really hopeful that we are on the right track. > ... > Here?s a quick summary of the changes with some consequences on the HotSpot code: > - all v-bytecodes are removed except vdefault and vwithfield At some point we may want to strip the v-prefix from those survivors. No hurry. > - all bytecodes operating on an object receiver are updated to support values as well, > except putfield and new Yep. > - single carrier type for both instances of object classes and instances of value classes > - this carrier type maps to the T_OBJECT BasicType > - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. > - qtos TosState is removed > - JNI: the jobject type can be used to carry either a reference to an object or an > array or a value. The type jvaluetype, sub-type of jobject, is used when only > a value class instance is expected > - Q?; remains the way to encode value classes in signature (fields and methods) I'd like to move towards an ACC_VALUE bit on both fields and classes. Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. > - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a > symbolic reference to either an object class or a value class > - the ;Q escape sequence is not used anymore in value class names > > > One important point of this exercise is to ensure that the migration of Value Based Classes > into Value Classes is possible, and doable with a reasonable complexity and costs. In addition > to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals > on how to deal with the VBC migration. I'm glad you are doing this analysis, not only because VBC migration is a wonderful goal, but also because I think the same analysis is necessary just to manage separate recompilation, even if we never decided to migrate a single class. In short, I see you are leaning hard on Q-descriptors, but I don't think you are getting enough value out of them, and they cause serious problems. More comments below? > > Migration of Value Based Classes into Value Classes: > - challenges: > - signature mismatch Goes away when/if we retire Q-descriptors! > - null Can be dealt with by assuming non-null and throwing dynamic NPEs as needed where Q types are in play. Also, we tolerate "polluting nulls" along paths where the Q/R distinction is not available, even if (at some point later on) we realize that it was a Q all along. Eventually, the polluting null will cause an NPE. (In my view, the NPE should happen later than one might prefer if it were a true coding error rather than a recompilation artifact. Catching polluting nulls early in the presence of recompilation requires too many heroics.) > - change in behavior Yes, that's the tricky part. > - proposal for signature mismatch: > - with LWVT, value class types in signatures are using the Q?; format > - legacy code is using signature with L?; format (because VBC are object classes) > - methods will have two signatures: > - true signature, which could include Q?; elements > - a L-ified signature where all Q?; elements are re-written with the L?; format > - method lookup still works by signature string comparisons > - the signature of the method being looked up will compared against both the > true and the L-ified signatures, if the looked up signature matches the L-ified > signature but not the true signature, it means a situation where legacy code > is trying to invoke migrated code has been detected, and additional work might > be required for the invocation (actions to be taken have to be defined) > - signature mismatch can also occur for fields, this is still being investigating, the > proposal will be updated as soon as we have a solution ready to be published This sort of thing is, for me, a rich argument against keeping Q-descriptors. > - proposal for null references leaking to migrated code > - having a null reference for a Value Based Class variable or field is valid in legacy code > but it becomes invalid when the Value Based Class has been migrated to a Value Class > - trying to prevent all references with a value class type to get a null value would be very > expensive (it would require to look at the stackmap for each assignment to a local variable) Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. > - the proposed solution is to allow null references for local variable and expression stack slots, > but forbid them for fields or array elements (bytecodes operating on fields and array have to > be updated to throw a NPE whenever a null reference is provided instead of a value class > instance) Yes, I think this is on the right track. On paths where a Q-type is needed we do a null check. That's the Java way. > - null references are likely to be an issue for JIT optimizations like passing values in registers > when a method is invoked. The proposed solution is to only allow null references for value classes > in legacy code, by detecting them and blocking them when leaking to migrated code. The > detection can be done at invocation time, when a mismatch between the signature expected > by the caller and the real signature of the callee is detected (see signature mismatch proposal above) At some point, a polluting null might reach code that "knows" there is a Q type (and may even "know" that it goes in an xmm register). That's the point where an NPE should be thrown. In some cases, a deopt might be appropriate, to correctly order the NPE by executing interpreter code. Note that this combination of techniques does not Q-descriptors. The lack of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you have to execute a little further before you get to code which "knows" that the null is illegal. > - the null reference should also be detected and blocked when it is used as a return value and the > type of the value to be returned is a value class type Doing this requires (a) Q-descriptors in method returns, (b) Remi's ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT doesn't have to tolerate nulls: It can deopt if it hits a surprise null, or perhaps throw an early NPE.) So, I am arguing for (c). > In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to > be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories > in the chart are not very precise, but we can use it as a starting point for our discussions. The chart > can also help defining which experiments could be done to estimate the costs of the different additional > checks needed to be added to existing bytecodes. The chart is really helpful, thanks. More comments later. Onward! ? John From david.holmes at oracle.com Mon Jan 22 06:30:49 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jan 2018 16:30:49 +1000 Subject: [Nestmates] RFR: 8195827: [Nestmates] jdk/internal/reflect/MethodAccessorGenerator.java should generate invokeinterface for private interface methods Message-ID: <3c90fe4b-ee8d-332e-e2be-aecf3d970dcf@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8195827/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8195827 Simple update previously overlooked - thanks Karen! We no longer use invokespecial for private interface methods. Thanks, David From david.holmes at oracle.com Mon Jan 22 06:31:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jan 2018 16:31:43 +1000 Subject: [Nestmates] RFR: 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java Message-ID: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8195826 webrev: http://cr.openjdk.java.net/~dholmes/8195826/webrev Get rid of old experimental ALLOW_NESTMATE_ACCESS support and recast directly using Reflection.areNestMates(a,b). Update quote of JVMS 5.4.4 access rules. Thanks, David From david.holmes at oracle.com Mon Jan 22 06:33:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jan 2018 16:33:43 +1000 Subject: [Nestmates] RFR: 8195828: [Nestmates] Remove leftover changes to invokespecial handling that are not needed Message-ID: <7837ad05-a5c5-b66e-bf43-842ea0709b72@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8195828 webrev: http://cr.openjdk.java.net/~dholmes/8195828/webrev/ Simple cleanup of changes not needed since we dropped use of invokespecial for nestmate support. This minimises differences with mainline version. Thanks, David From karen.kinnear at oracle.com Mon Jan 22 22:11:49 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 22 Jan 2018 17:11:49 -0500 Subject: [Nestmates] RFR: 8195827: [Nestmates] jdk/internal/reflect/MethodAccessorGenerator.java should generate invokeinterface for private interface methods In-Reply-To: <3c90fe4b-ee8d-332e-e2be-aecf3d970dcf@oracle.com> References: <3c90fe4b-ee8d-332e-e2be-aecf3d970dcf@oracle.com> Message-ID: <84E4EFEC-E484-436B-AE04-C547FC0BC0FB@oracle.com> Looks good - thanks David! Karen > On Jan 22, 2018, at 1:30 AM, David Holmes wrote: > > webrev: http://cr.openjdk.java.net/~dholmes/8195827/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8195827 > > Simple update previously overlooked - thanks Karen! We no longer use invokespecial for private interface methods. > > Thanks, > David From karen.kinnear at oracle.com Mon Jan 22 22:27:15 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 22 Jan 2018 17:27:15 -0500 Subject: [Nestmates] RFR: 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java In-Reply-To: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> References: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> Message-ID: <40968EE4-060D-42E5-96A5-F6713419D5D6@oracle.com> Forgot to ask - do you have a test for this? thanks, Karen > On Jan 22, 2018, at 1:31 AM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195826 > webrev: http://cr.openjdk.java.net/~dholmes/8195826/webrev > > Get rid of old experimental ALLOW_NESTMATE_ACCESS support and recast directly using Reflection.areNestMates(a,b). > > Update quote of JVMS 5.4.4 access rules. > > Thanks, > David From karen.kinnear at oracle.com Mon Jan 22 22:28:04 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 22 Jan 2018 17:28:04 -0500 Subject: [Nestmates] RFR: 8195827: [Nestmates] jdk/internal/reflect/MethodAccessorGenerator.java should generate invokeinterface for private interface methods In-Reply-To: <84E4EFEC-E484-436B-AE04-C547FC0BC0FB@oracle.com> References: <3c90fe4b-ee8d-332e-e2be-aecf3d970dcf@oracle.com> <84E4EFEC-E484-436B-AE04-C547FC0BC0FB@oracle.com> Message-ID: Oops - this is the one I forgot to ask - do you have a test for this? thanks, Karen p.s. ignore my other email on 8195826 - not relevant. > On Jan 22, 2018, at 5:11 PM, Karen Kinnear wrote: > > Looks good - thanks David! > > Karen > >> On Jan 22, 2018, at 1:30 AM, David Holmes wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8195827/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8195827 >> >> Simple update previously overlooked - thanks Karen! We no longer use invokespecial for private interface methods. >> >> Thanks, >> David > From david.holmes at oracle.com Mon Jan 22 22:29:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 08:29:51 +1000 Subject: [Nestmates] RFR: 8195827: [Nestmates] jdk/internal/reflect/MethodAccessorGenerator.java should generate invokeinterface for private interface methods In-Reply-To: <84E4EFEC-E484-436B-AE04-C547FC0BC0FB@oracle.com> References: <3c90fe4b-ee8d-332e-e2be-aecf3d970dcf@oracle.com> <84E4EFEC-E484-436B-AE04-C547FC0BC0FB@oracle.com> Message-ID: <84b0dae6-5bac-0ea2-5ba5-c91382422e1e@oracle.com> Thanks Karen! David On 23/01/2018 8:11 AM, Karen Kinnear wrote: > Looks good - thanks David! > > Karen > >> On Jan 22, 2018, at 1:30 AM, David Holmes wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8195827/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8195827 >> >> Simple update previously overlooked - thanks Karen! We no longer use invokespecial for private interface methods. >> >> Thanks, >> David > From david.holmes at oracle.com Mon Jan 22 22:33:09 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 08:33:09 +1000 Subject: [Nestmates] RFR: 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java In-Reply-To: <40968EE4-060D-42E5-96A5-F6713419D5D6@oracle.com> References: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> <40968EE4-060D-42E5-96A5-F6713419D5D6@oracle.com> Message-ID: <5b9aaa2c-855e-4e96-d305-86b91f9f7a58@oracle.com> On 23/01/2018 8:27 AM, Karen Kinnear wrote: > Forgot to ask - do you have a test for this? Numerous MethodHandle tests exercise this access checking logic: runtime/Nestmates/privateConstructors/TestMethodHandles.java runtime/Nestmates/privateFields/TestMethodHandles.java runtime/Nestmates/privateMethods/TestMethodHandles.java runtime/Nestmates/privateStaticFields/TestMethodHandles.java runtime/Nestmates/privateStaticMethods/TestMethodHandles.java Thanks, David > thanks, > Karen > >> On Jan 22, 2018, at 1:31 AM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195826 >> webrev: http://cr.openjdk.java.net/~dholmes/8195826/webrev >> >> Get rid of old experimental ALLOW_NESTMATE_ACCESS support and recast directly using Reflection.areNestMates(a,b). >> >> Update quote of JVMS 5.4.4 access rules. >> >> Thanks, >> David > From david.holmes at oracle.com Mon Jan 22 22:34:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 08:34:55 +1000 Subject: [Nestmates] RFR: 8195827: [Nestmates] jdk/internal/reflect/MethodAccessorGenerator.java should generate invokeinterface for private interface methods In-Reply-To: References: <3c90fe4b-ee8d-332e-e2be-aecf3d970dcf@oracle.com> <84E4EFEC-E484-436B-AE04-C547FC0BC0FB@oracle.com> Message-ID: On 23/01/2018 8:28 AM, Karen Kinnear wrote: > Oops - this is the one I forgot to ask - do you have a test for this? All the reflection tests are run twice e.g. 29 * @run main TestReflection 30 * @run main/othervm -Dsun.reflect.noInflation=true TestReflection 31 */ 32 33 // The first run will use NativeMethodAccessor and due to the limited number 34 // of calls we will not reach the inflation threshold. 35 // The second run disables inflation so we will use the GeneratedMethodAccessor 36 // instead. In this way both sets of Reflection classes are tested. > thanks, > Karen > > p.s. ignore my other email on 8195826 - not relevant. Too late :) Thanks, David >> On Jan 22, 2018, at 5:11 PM, Karen Kinnear wrote: >> >> Looks good - thanks David! >> >> Karen >> >>> On Jan 22, 2018, at 1:30 AM, David Holmes wrote: >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8195827/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8195827 >>> >>> Simple update previously overlooked - thanks Karen! We no longer use invokespecial for private interface methods. >>> >>> Thanks, >>> David >> > From david.holmes at oracle.com Tue Jan 23 06:41:47 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 23 Jan 2018 06:41:47 +0000 Subject: hg: valhalla/valhalla: 205 new changesets Message-ID: <201801230642.w0N6g1V1005786@aojmv0008.oracle.com> Changeset: 9a29aa153c20 Author: xiaofeya Date: 2018-01-08 07:13 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9a29aa153c20 8194724: Problem list java/net/httpclient/SplitResponseSSL.java Reviewed-by: chegar ! test/jdk/ProblemList.txt Changeset: d3b1fc1bda9c Author: martin Date: 2018-01-03 13:17 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d3b1fc1bda9c 8145371: ClassCastException thrown in LambdaFormEditor.getInCache Summary: Read field into local to avoid customization race Reviewed-by: vlivanov, jrose, psandoz ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java Changeset: 37d2147852fc Author: redestad Date: 2018-01-10 00:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/37d2147852fc 8134459: java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java timed out Reviewed-by: psandoz, rriggs ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java ! test/jdk/lib/testlibrary/bootlib/java.base/java/util/stream/LambdaTestHelpers.java Changeset: 50cd89fe209f Author: jjiang Date: 2018-01-09 18:36 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/50cd89fe209f 8194257: javax/net/ssl/compatibility/Compatibility.java should be updated for JDK 6 after JDK-8174748 Summary: Marks some of AES_256 and AES_128 cipher suites are JDK 6 enabled Reviewed-by: xuelei ! test/jdk/javax/net/ssl/compatibility/Parameter.java Changeset: abd7f09d0a79 Author: naoto Date: 2018-01-11 12:47 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/abd7f09d0a79 8194148: bcp47u/SymbolsTests.java and FormatTests.java fail on th_TH locale Reviewed-by: rriggs ! test/jdk/java/util/Locale/bcp47u/FormatTests.java ! test/jdk/java/util/Locale/bcp47u/SymbolsTests.java Changeset: b51755ee57f6 Author: jjg Date: 2018-01-11 13:47 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b51755ee57f6 8151850: eliminate javax.tools.FileManagerUtils Reviewed-by: vromero - src/java.compiler/share/classes/javax/tools/FileManagerUtils.java ! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java Changeset: 7a700fd0ad50 Author: jjg Date: 2018-01-11 15:06 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7a700fd0ad50 8194893: javac -verbose prints wrong paths for output files Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/langtools/tools/javac/jvm/VerboseOutTest.java Changeset: 7f57c5908c57 Author: hannesw Date: 2018-01-12 10:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7f57c5908c57 8157251: BeanLinker relinks array length operations for array types Reviewed-by: hannesw, jlaskey, attila Contributed-by: priya.lakshmi.muthuswamy at oracle.com ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java + test/nashorn/script/basic/JDK-8157251.js + test/nashorn/script/basic/JDK-8157251.js.EXPECTED Changeset: a5f815d1060b Author: mcimadamore Date: 2018-01-12 16:49 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a5f815d1060b 8194932: no ambuguity error is emitted if classfile contains two identical methods with different return types Summary: add recovery logic when classfile contains two signature-equivalent methods Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/langtools/tools/javac/8194932/Foo.jcod + test/langtools/tools/javac/8194932/T8194932.java + test/langtools/tools/javac/8194932/T8194932.out Changeset: bdbbf56c302e Author: bpb Date: 2018-01-12 11:06 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/bdbbf56c302e 8165852: (fs) Mount point not found for a file which is present in overlayfs Summary: Check /proc/mounts when the device ID boundary is reached Reviewed-by: alanb ! src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java ! src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java Changeset: 6a1c3a5e04f3 Author: bpb Date: 2018-01-12 11:06 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6a1c3a5e04f3 4358774: Add null InputStream and OutputStream Reviewed-by: alanb, prappo, reinhapa, rriggs ! src/java.base/share/classes/java/io/InputStream.java ! src/java.base/share/classes/java/io/OutputStream.java + test/jdk/java/io/InputStream/NullInputStream.java ! test/jdk/java/io/InputStream/ReadParams.java + test/jdk/java/io/OutputStream/NullOutputStream.java ! test/jdk/java/io/OutputStream/WriteParams.java Changeset: 0bce2ae39928 Author: thartmann Date: 2017-12-15 16:51 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0bce2ae39928 8193608: Quarantine test/hotspot/jtreg/compiler/codegen/Test6896617.java until JDK-8193479 is fixed Summary: Added test to ProblemList.txt Reviewed-by: vlivanov ! test/hotspot/jtreg/ProblemList.txt Changeset: 474cec233fb2 Author: hseigel Date: 2017-12-15 11:23 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/474cec233fb2 8154587: Resolution fails for default method named 'clone' Summary: Make sure default methods with the same names as those in j.l.Object get put in the default methods table where resolution can find them. Reviewed-by: acorn, lfoltan ! src/hotspot/share/classfile/defaultMethods.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/klassVtable.hpp + test/hotspot/jtreg/runtime/clone/AbstractClone.java + test/hotspot/jtreg/runtime/clone/AbstractNoClones.jasm + test/hotspot/jtreg/runtime/clone/DefaultClone.jasm + test/hotspot/jtreg/runtime/clone/DefaultFinalize.jasm + test/hotspot/jtreg/runtime/clone/DefaultHashCode.jasm + test/hotspot/jtreg/runtime/clone/DefaultNoCloneInC.jasm + test/hotspot/jtreg/runtime/clone/LocalClone.jasm + test/hotspot/jtreg/runtime/clone/NoClones.jasm + test/hotspot/jtreg/runtime/clone/invokevirtual/DefMethClone.jasm + test/hotspot/jtreg/runtime/clone/invokevirtual/HasLocalClone.jasm + test/hotspot/jtreg/runtime/clone/invokevirtual/I1.java + test/hotspot/jtreg/runtime/clone/invokevirtual/I1Abstr.java + test/hotspot/jtreg/runtime/clone/invokevirtual/NoLocalClone.jasm + test/hotspot/jtreg/runtime/clone/invokevirtual/NoLocalCloneAbstr.jasm + test/hotspot/jtreg/runtime/clone/invokevirtual/SuperClass.jasm Changeset: 0c0b618a20b1 Author: jwilhelm Date: 2017-12-15 16:54 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0c0b618a20b1 Merge - src/java.base/share/classes/java/util/zip/ZStreamRef.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Gen.java - src/jdk.compiler/share/classes/com/sun/tools/javah/InternalError.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JNI.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JavahFileManager.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java - src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTool.java - src/jdk.compiler/share/classes/com/sun/tools/javah/LLNI.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Main.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Mangle.java - src/jdk.compiler/share/classes/com/sun/tools/javah/NativeHeaderTool.java - src/jdk.compiler/share/classes/com/sun/tools/javah/TypeSignature.java - src/jdk.compiler/share/classes/com/sun/tools/javah/Util.java - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n.properties - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n_ja.properties - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties - src/jdk.compiler/share/classes/com/sun/tools/javah/resources/version.properties-template - test/jdk/sun/security/tools/keytool/p12importks.sh - test/langtools/tools/javac/T8152360/DeprecateJavahTest.java - test/langtools/tools/javac/nativeHeaders/javahComparison/CompareTest.java - test/langtools/tools/javac/nativeHeaders/javahComparison/TestClass1.java - test/langtools/tools/javac/nativeHeaders/javahComparison/TestClass4.java - test/langtools/tools/javac/nativeHeaders/javahComparison/TestClass5.java - test/langtools/tools/javah/4942232/ParamClassTest.java - test/langtools/tools/javah/4942232/Test.java - test/langtools/tools/javah/6257087/T6257087.java - test/langtools/tools/javah/6572945/T6572945.java - test/langtools/tools/javah/6572945/TestClass1.java - test/langtools/tools/javah/6572945/TestClass2.java - test/langtools/tools/javah/6572945/TestClass3.java - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass1.h - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner1.h - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner2.h - test/langtools/tools/javah/6572945/gold/jni.dir.1/TestClass2.h - test/langtools/tools/javah/6572945/gold/jni.file.1 - test/langtools/tools/javah/6572945/gold/jni.file.2 - test/langtools/tools/javah/6572945/gold/jni.file.3 - test/langtools/tools/javah/ModuleClass.java - test/langtools/tools/javah/ReadOldClass.sh - test/langtools/tools/javah/T4942232/MissingParamClassTest.java - test/langtools/tools/javah/T5070898.java - test/langtools/tools/javah/T6893943.java - test/langtools/tools/javah/T6994608.java - test/langtools/tools/javah/T7126832/T7126832.java - test/langtools/tools/javah/T7126832/java.java - test/langtools/tools/javah/T7185778.java - test/langtools/tools/javah/TestHelpOpts.java - test/langtools/tools/javah/VersionTest.java - test/langtools/tools/javah/constMacroTest/ConstMacroTest.java - test/langtools/tools/lib/toolbox/JavahTask.java Changeset: f82e79958beb Author: hseigel Date: 2017-12-15 15:13 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f82e79958beb 8167372: Add code to check for getting oops while thread is in native Summary: Add asserts that detect when a thread is getting oops while in native Reviewed-by: coleenp, shade, jiangli, gtriantafill ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp Changeset: 08b8cc40cb61 Author: goetz Date: 2017-12-14 12:57 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/08b8cc40cb61 8193509: Test dynamic path to retrieve active processor count. Reviewed-by: dholmes, mdoerr + test/hotspot/jtreg/runtime/os/TestUseCpuAllocPath.java Changeset: 7969cc1b94ee Author: rehn Date: 2017-12-18 12:11 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7969cc1b94ee 8193514: UseMembar should not be obsoleted yet Reviewed-by: dcubed, acorn, mdoerr ! src/hotspot/share/runtime/arguments.cpp Changeset: 7cc7de9bf4a4 Author: coleenp Date: 2017-12-19 06:29 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7cc7de9bf4a4 8186903: Remove j-types from Atomic Summary: Make jlong into int64_t, atomic_FN_long into atomic_FN_int64, make jbyte to u_char. Reviewed-by: dholmes, dcubed ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/zero/stubGenerator_zero.cpp ! src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp ! src/hotspot/os_cpu/bsd_x86/bsd_x86_32.s ! src/hotspot/os_cpu/bsd_zero/atomic_bsd_zero.hpp ! src/hotspot/os_cpu/linux_arm/atomic_linux_arm.hpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.hpp ! src/hotspot/os_cpu/linux_x86/atomic_linux_x86.hpp ! src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp ! src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.hpp ! src/hotspot/os_cpu/solaris_x86/atomic_solaris_x86.hpp ! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp ! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.hpp ! src/hotspot/os_cpu/windows_x86/atomic_windows_x86.hpp ! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp ! src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp Changeset: 7312ae4465d6 Author: iklam Date: 2017-12-04 08:59 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7312ae4465d6 8193672: [test] Enhance vm.cds property to check for all conditions required to run CDS tests Reviewed-by: dholmes, dsamersoff, simonis ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/runtime/SharedArchiveFile/ArchiveDoesNotExist.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/BootAppendTests.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentCompactStrings.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsSameObjectAlignment.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/DefaultUseWithClient.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSharedDictionary.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SASymbolTableTest.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedBaseAddress.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStrings.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedSymbolTableBucketSize.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SpaceUtilizationCheck.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformInterfaceAndImplementor.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperAndSubClasses.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperSubTwoPckgs.java ! test/hotspot/jtreg/runtime/appcds/AppendClasspath.java ! test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java ! test/hotspot/jtreg/runtime/appcds/CaseSensitiveClassPath.java ! test/hotspot/jtreg/runtime/appcds/ClassLoaderTest.java ! test/hotspot/jtreg/runtime/appcds/ClassPathAttr.java ! test/hotspot/jtreg/runtime/appcds/CommandLineFlagCombo.java ! test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java ! test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java ! test/hotspot/jtreg/runtime/appcds/DumpClassList.java ! test/hotspot/jtreg/runtime/appcds/ExtraSymbols.java ! test/hotspot/jtreg/runtime/appcds/FieldAnnotationsTest.java ! test/hotspot/jtreg/runtime/appcds/FreeUnusedMetadata.java ! test/hotspot/jtreg/runtime/appcds/HelloExtTest.java ! test/hotspot/jtreg/runtime/appcds/HelloTest.java ! test/hotspot/jtreg/runtime/appcds/IgnoreEmptyClassPaths.java ! test/hotspot/jtreg/runtime/appcds/JvmtiAddPath.java ! test/hotspot/jtreg/runtime/appcds/MismatchedUseAppCDS.java ! test/hotspot/jtreg/runtime/appcds/MissingSuperTest.java ! test/hotspot/jtreg/runtime/appcds/MultiProcessSharing.java ! test/hotspot/jtreg/runtime/appcds/MultiReleaseJars.java ! test/hotspot/jtreg/runtime/appcds/OldClassTest.java ! test/hotspot/jtreg/runtime/appcds/PackageSealing.java ! test/hotspot/jtreg/runtime/appcds/ParallelLoad2.java ! test/hotspot/jtreg/runtime/appcds/ParallelLoadTest.java ! test/hotspot/jtreg/runtime/appcds/PrintSharedArchiveAndExit.java ! test/hotspot/jtreg/runtime/appcds/ProhibitedPackage.java ! test/hotspot/jtreg/runtime/appcds/ProtectionDomain.java ! test/hotspot/jtreg/runtime/appcds/RewriteBytecodesTest.java ! test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java ! test/hotspot/jtreg/runtime/appcds/SharedBaseAddress.java ! test/hotspot/jtreg/runtime/appcds/SharedPackages.java ! test/hotspot/jtreg/runtime/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/appcds/SpecifySysLoaderProp.java ! test/hotspot/jtreg/runtime/appcds/TraceLongClasspath.java ! test/hotspot/jtreg/runtime/appcds/UseAppCDS.java ! test/hotspot/jtreg/runtime/appcds/VerifierTest_0.java ! test/hotspot/jtreg/runtime/appcds/VerifierTest_1A.java ! test/hotspot/jtreg/runtime/appcds/VerifierTest_1B.java ! test/hotspot/jtreg/runtime/appcds/VerifierTest_2.java ! test/hotspot/jtreg/runtime/appcds/WideIloadTest.java ! test/hotspot/jtreg/runtime/appcds/WrongClasspath.java ! test/hotspot/jtreg/runtime/appcds/XShareAutoWithChangedJar.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferences.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/RangeNotWithinHeap.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatA.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatB.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatC.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatD.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatE.java ! test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java ! test/hotspot/jtreg/runtime/appcds/customLoader/LoaderSegregationTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestMultiFP.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestSingleFP.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ProhibitedPackageNamesTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ProtectionDomain.java ! test/hotspot/jtreg/runtime/appcds/customLoader/SameNameInTwoLoadersTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnintendedLoadersTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnsupportedPlatforms.java ! test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java ! test/hotspot/jtreg/runtime/appcds/javaldr/CheckAnonymousClass.java ! test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDump.java ! test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/CheckUnsupportedDumpingOptions.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/AppClassInCP.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/CustomPackage.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/MismatchedPatchModule.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchDir.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchJavaBase.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/Simple.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/TwoJars.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/limitmods/LimitModsTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/OverrideTests.java ! test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHookTest.java ! test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java ! test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java ! test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformInterfaceImplementorAppCDS.java ! test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformSuperSubAppCDS.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/ExerciseGC.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/FlagCombo.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/InternSharedString.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/InvalidFileFormat.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LargePages.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LockSharedStrings.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasicPlus.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsStress.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWbTest.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: 1d24b76cf639 Author: iklam Date: 2017-12-19 11:29 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1d24b76cf639 8191374: Improve error message when CDS is not supported on exploded build Reviewed-by: jiangli, hseigel ! src/hotspot/share/classfile/classLoader.cpp Changeset: d55bee3727de Author: dholmes Date: 2017-12-19 17:31 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d55bee3727de 8193840: Add compiler/c2/Test8007294.java to the problem list Reviewed-by: coleenp ! test/hotspot/jtreg/ProblemList.txt Changeset: de2e4ff493bf Author: coleenp Date: 2017-12-20 10:05 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/de2e4ff493bf 8152957: Improve specificity of safepoint logging to print safepoint type Summary: upgrade safepoint begin logs to Info logging, which has the reason. Reviewed-by: dholmes, hseigel, zgu ! src/hotspot/share/runtime/safepoint.cpp Changeset: 9a5bcee1a706 Author: iklam Date: 2017-12-20 11:30 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9a5bcee1a706 8193897: JDK-8191374 caused windows_i586 build to fail Reviewed-by: hseigel ! src/hotspot/share/classfile/classLoader.cpp Changeset: 6e69aea2aee7 Author: gadams Date: 2017-12-20 13:41 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6e69aea2aee7 8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 18fb03624696 Author: jwilhelm Date: 2017-12-21 00:07 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/18fb03624696 Merge ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/native/libjava/System.c - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java Changeset: ca9489245872 Author: jcbeyler Date: 2017-12-20 11:00 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ca9489245872 8191987: JDK-8190862 work for arch ppc64 Summary: Cleanup interpreter TLAB code Reviewed-by: mdoerr, goetz ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp Changeset: b7af6f568d00 Author: chegar Date: 2017-12-22 15:55 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b7af6f568d00 8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass Reviewed-by: alanb, dfuchs, dholmes, lancea, mchung, rriggs ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjava/reorder-sparc ! make/mapfiles/libjava/reorder-sparcv9 ! make/mapfiles/libjava/reorder-x86 ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/native/libjava/Reflection.c - src/jdk.unsupported/share/classes/sun/reflect/Reflection.java - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassWithDepth.java - test/jdk/sun/reflect/Reflection/GetCallerClassWithDepth.java ! test/langtools/tools/jdeps/jdkinternals/RemovedJDKInternals.java + test/langtools/tools/jdeps/jdkinternals/patches/jdk.unsupported/sun/reflect/Reflection.java ! test/langtools/tools/jdeps/jdkinternals/src/p/Main.java Changeset: f3907e64eea2 Author: rraghavan Date: 2017-12-22 09:51 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f3907e64eea2 8193699: aarch64 fails to build after 8167372 Summary: added ThreadInVMfromUnknown support Reviewed-by: smonteith, vlivanov ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: 7b5c930b878c Author: glaubitz Date: 2017-11-29 13:58 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7b5c930b878c 8192123: Zero should use compiler built-ins for atomics on linux-arm Reviewed-by: aph ! src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp Changeset: 614068b0ddd7 Author: dnsimon Date: 2017-12-22 18:34 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/614068b0ddd7 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes Reviewed-by: never, dlong ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java Changeset: b97818fba2b0 Author: jcbeyler Date: 2017-12-18 15:38 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b97818fba2b0 8191027: JDK-8190862 work for arch x86/x64 Summary: Fixed Interpreter never refills TLAB Reviewed-by: tschatzl, mdoerr, rehn ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: 4aed7c563f7e Author: jcbeyler Date: 2017-12-19 20:10 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4aed7c563f7e 8191986: JDK-8190862 work for arch aarch64 Summary: Fixed Interpreter never refills TLAB Reviewed-by: dsamersoff, adinn, tschatzl, rehn ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Changeset: afb2284bb487 Author: jcbeyler Date: 2017-12-19 19:55 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/afb2284bb487 8191989: JDK-8190862 work for arch sparc Summary: Fixed Interpreter never refills TLAB Reviewed-by: tschatzl, rehn ! src/hotspot/cpu/sparc/templateTable_sparc.cpp Changeset: 9ca19ebea22d Author: rkennke Date: 2017-12-05 10:43 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9ca19ebea22d 8193193: AArch64: immByteMapBase operand generated for non-CardTable GCs Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: 258a4dab74a7 Author: gadams Date: 2018-01-02 07:50 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/258a4dab74a7 8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix Reviewed-by: cjplummer, sspitsyn ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Changeset: bda5211e7876 Author: goetz Date: 2017-12-21 09:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/bda5211e7876 8193927: Optimize scanning code for oops. Reviewed-by: simonis, mdoerr, aph ! src/hotspot/cpu/aarch64/relocInfo_aarch64.hpp ! src/hotspot/cpu/arm/relocInfo_arm.hpp ! src/hotspot/cpu/ppc/relocInfo_ppc.hpp ! src/hotspot/cpu/s390/relocInfo_s390.hpp ! src/hotspot/cpu/sparc/relocInfo_sparc.hpp ! src/hotspot/cpu/x86/relocInfo_x86.hpp ! src/hotspot/cpu/zero/relocInfo_zero.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: abf1d797e380 Author: aph Date: 2018-01-03 17:29 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/abf1d797e380 8193260: AArch64: JVMCI: Implement trampoline calls Reviewed-by: adinn ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp ! src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp ! src/hotspot/cpu/sparc/compiledIC_sparc.cpp ! src/hotspot/cpu/sparc/jvmciCodeInstaller_sparc.cpp ! src/hotspot/cpu/x86/compiledIC_x86.cpp ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp Changeset: 51825789dd89 Author: kbarrett Date: 2018-01-04 18:18 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/51825789dd89 8194406: Use Atomic::replace_if_null Reviewed-by: coleenp, dholmes ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/parallel/gcTaskThread.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/jvmtiRawMonitor.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/services/mallocSiteTable.cpp ! src/hotspot/share/utilities/bitMap.cpp Changeset: a5548cf24286 Author: dholmes Date: 2018-01-04 22:54 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a5548cf24286 8194279: support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai Reviewed-by: dholmes, kvn Contributed-by: Vic Wang ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: 4f647519c8be Author: jwilhelm Date: 2018-01-05 22:02 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4f647519c8be Merge ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/thread.cpp - src/jdk.unsupported/share/classes/sun/reflect/Reflection.java ! test/hotspot/jtreg/ProblemList.txt - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassWithDepth.java - test/jdk/sun/reflect/Reflection/GetCallerClassWithDepth.java Changeset: 7f11a1699ef6 Author: sherman Date: 2018-01-12 14:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7f11a1699ef6 8194667: Regex: Serialization doesn't work with match flags Reviewed-by: rriggs ! src/java.base/share/classes/java/util/regex/Pattern.java ! test/jdk/java/util/regex/RegExTest.java Changeset: fb56735cb46a Author: iignatyev Date: 2018-01-12 14:33 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fb56735cb46a 8195067: problem list tools/javac/jvm/VerboseOutTest.java Reviewed-by: jjg ! test/langtools/ProblemList.txt Changeset: d53732d23ade Author: gadams Date: 2018-01-13 18:33 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d53732d23ade 8031482: Some jcmds generate output with a \n as a separator rather than \r\n on Windows Reviewed-by: cjplummer, sspitsyn, dholmes ! test/jdk/ProblemList.txt ! test/jdk/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java Changeset: a65e8281b27c Author: hannesw Date: 2018-01-15 11:07 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a65e8281b27c 8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM Reviewed-by: sundar, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! test/nashorn/src/jdk/nashorn/api/scripting/test/ScriptEngineSecurityTest.java Changeset: fdf6715229b1 Author: amlu Date: 2018-01-08 10:15 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fdf6715229b1 8194666: ProblemList update for bugid associated with PreferredKey.java, ConcurrentHashMapTest and SSLSocketParametersTest.sh Reviewed-by: xuelei ! test/jdk/ProblemList.txt Changeset: 069c82c31914 Author: amlu Date: 2018-01-08 11:20 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/069c82c31914 8194662: Problem list com/sun/jndi/ldap/LdapTimeoutTest.java Reviewed-by: dholmes ! test/jdk/ProblemList.txt Changeset: 78aaea7388ad Author: hannesw Date: 2018-01-08 17:16 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/78aaea7388ad 8193567: Conversion of comparison nodes affects local slots in optimistic continuation Reviewed-by: jlaskey, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java + test/nashorn/script/basic/JDK-8193567.js Changeset: c94c352dc400 Author: vromero Date: 2018-01-08 14:06 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c94c352dc400 8187487: crash with classes with same binary name Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/NestedInnerClassNames.out + test/langtools/tools/javac/T8187487/CrashWithDuplicateClassNamesTest.java + test/langtools/tools/javac/T8187487/CrashWithDuplicateClassNamesTest.out + test/langtools/tools/javac/diags/examples/SameBinaryName.java Changeset: 239c7d9bb192 Author: darcy Date: 2018-01-08 17:32 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/239c7d9bb192 8187951: Update javax.lang.model.SourceVersion for "var" name Reviewed-by: jjg, mcimadamore ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java Changeset: 899a137688b8 Author: sballal Date: 2018-01-09 15:21 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/899a137688b8 8194067: [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings Reviewed-by: dholmes, sspitsyn ! test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java Changeset: f0e55fb9cfa3 Author: thartmann Date: 2017-12-15 16:51 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f0e55fb9cfa3 8193608: Quarantine test/hotspot/jtreg/compiler/codegen/Test6896617.java until JDK-8193479 is fixed Summary: Added test to ProblemList.txt Reviewed-by: vlivanov ! test/hotspot/jtreg/ProblemList.txt Changeset: 13f6856e8489 Author: goetz Date: 2018-01-09 16:24 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/13f6856e8489 8194742: Writing replay data crashes: task is NULL Summary: Added missing NULL check. Reviewed-by: thartmann ! src/hotspot/share/ci/ciEnv.cpp Changeset: 2e5226ca1329 Author: jjg Date: 2018-01-09 17:03 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2e5226ca1329 8185986: redundant/obsolete overview.html pages Reviewed-by: darcy - src/java.compiler/share/classes/javax/lang/model/overview.html - src/java.compiler/share/classes/javax/tools/overview.html - src/jdk.jdeps/share/classes/com/sun/tools/javap/overview.html Changeset: 25732365355c Author: vromero Date: 2018-01-09 22:30 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/25732365355c 8194836: delta apply changesets for JDK-8192885 and JDK-8175883 Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java - test/langtools/tools/javac/T8192885/AddGotoAfterForLoopToLNTTest.java ! test/langtools/tools/javac/flow/tests/TestCaseForEach.java Changeset: 5db30620a3db Author: thartmann Date: 2018-01-10 09:04 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5db30620a3db 8191362: [Graal] gc/g1/TestShrinkAuxiliaryData tests crash with "assert(check_klass_alignment(result)) failed: address not aligned" Summary: Graal does not respect ObjectAlignmentInBytes VM option. Reviewed-by: kvn ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaAccessProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/NewArrayStub.java Changeset: 478e77658965 Author: mdoerr Date: 2018-01-10 11:09 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/478e77658965 8194258: PPC64 safepoint mechanism: Fix initialization on AIX and support SIGTRAP Summary: Use mmap on AIX to allocate protected page. Use trap instructions for polling if UseSIGTRAP is enabled. Reviewed-by: rehn, goetz ! src/hotspot/cpu/ppc/globalDefinitions_ppc.hpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/os/aix/safepointMechanism_aix.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! test/hotspot/jtreg/runtime/logging/OsCpuLoggingTest.java Changeset: 282262d5031b Author: rraghavan Date: 2018-01-10 02:31 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/282262d5031b 8193607: Test failure with java.lang.ClassNotFoundException: compiler.tiered.LevelTransitionTest Summary: Added compiler.tiered.LevelTransitionTest to @build Reviewed-by: thartmann Contributed-by: ramkumar.sunderbabu at oracle.com ! test/hotspot/jtreg/compiler/tiered/LevelTransitionTest.java Changeset: 5207db413697 Author: tschatzl Date: 2018-01-10 10:21 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5207db413697 8194824: Add gc/stress/gclocker/TestGCLockerWithParallel.java to the ProblemList file Reviewed-by: ehelin, kbarrett ! test/hotspot/jtreg/ProblemList.txt Changeset: e595b672a50b Author: tschatzl Date: 2018-01-10 12:11 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e595b672a50b Merge Changeset: 2fe2d312e6ce Author: lkorinth Date: 2018-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2fe2d312e6ce 8194681: G1 uses young free cset time when reporting non-young free cset times Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: d41a61e52a84 Author: serb Date: 2018-01-10 07:21 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d41a61e52a84 8193673: Regression manual Test javax/swing/JFileChooser/6515169/bug6515169.java fails Reviewed-by: erikj, psadhukhan ! make/gensrc/Gensrc-java.desktop.gmk + test/jdk/javax/swing/UIManager/8193673/TestProperties.java Changeset: e8e8c9e6ccf8 Author: jjg Date: 2018-01-10 15:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e8e8c9e6ccf8 8194901: remove interim code from javax.tools.ToolProvider Reviewed-by: mchung ! src/java.compiler/share/classes/javax/tools/ToolProvider.java Changeset: 5b834ec96236 Author: vromero Date: 2018-01-10 22:52 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5b834ec96236 8187805: bogus RuntimeVisibleTypeAnnotations for unused local in a block Reviewed-by: sadayapalam ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java + test/langtools/tools/javac/T8187805/BogusRTTAForUnusedVarTest.java Changeset: 9608f7f41c4e Author: vlivanov Date: 2018-01-12 01:52 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9608f7f41c4e 8188145: MethodHandle resolution should follow JVMS sequence of lookup by name & type before type descriptor resolution Reviewed-by: kvn, psandoz ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/methodHandles.hpp ! src/java.base/share/classes/java/lang/invoke/MemberName.java + test/hotspot/jtreg/runtime/invokedynamic/MethodHandleConstantHelper.jasm + test/hotspot/jtreg/runtime/invokedynamic/MethodHandleConstantTest.java Changeset: 0da9fb7d7d04 Author: jjg Date: 2018-01-11 15:38 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0da9fb7d7d04 8181878: javadoc should support/ignore --add-opens Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java + test/langtools/jdk/javadoc/tool/AddOpensTest.java + test/langtools/tools/javadoc/AddOpensTest.java Changeset: 7d286141598c Author: iklam Date: 2018-01-11 16:40 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7d286141598c 8193664: AppCDS tests should use -XX:+UnlockCommercialFeatures when running with commercial JDK Reviewed-by: jiangli, mseledtsov, dholmes ! test/hotspot/jtreg/runtime/appcds/TestCommon.java ! test/hotspot/jtreg/runtime/appcds/UseAppCDS.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: 94dd6cda265d Author: lana Date: 2018-01-12 05:06 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/94dd6cda265d Added tag jdk-10+39 for changeset 5b834ec96236 ! .hgtags Changeset: e2c862ab9601 Author: lana Date: 2018-01-12 05:07 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e2c862ab9601 Merge Changeset: 482ede6c4936 Author: amlu Date: 2018-01-12 14:09 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/482ede6c4936 8194959: Correct test tag to move bugid from @test to @bug Reviewed-by: sundar ! test/jdk/java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java ! test/jdk/java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java ! test/jdk/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java ! test/jdk/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java ! test/jdk/java/lang/StackWalker/SecurityExceptions.java ! test/jdk/java/lang/System/LoggerFinder/internal/SystemLoggerInPlatformLoader/SystemLoggerInPlatformLoader.java ! test/jdk/java/security/cert/PKIXBuilderParameters/InvalidParameters.java ! test/jdk/java/security/cert/PKIXParameters/InvalidParameters.java ! test/jdk/java/util/Arrays/StreamAndSpliterator.java ! test/jdk/java/util/Arrays/largeMemory/ParallelPrefix.java ! test/jdk/java/util/Base64/TestBase64.java ! test/jdk/java/util/Base64/TestBase64Golden.java ! test/jdk/java/util/logging/LogManager/LinkageErrorTest.java Changeset: f6f6d86b90e7 Author: kaddepalli Date: 2018-01-12 14:01 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f6f6d86b90e7 8194044: Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails Reviewed-by: psadhukhan, jdv, ssadetsky ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java + test/jdk/javax/swing/JFileChooser/8194044/FileSystemRootTest.java Changeset: 30243cf1503e Author: jjg Date: 2018-01-12 11:41 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/30243cf1503e 8194955: Warn when default HTML version is used Reviewed-by: ksrini, bpatel ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties + test/langtools/jdk/javadoc/doclet/testHtmlWarning/TestHtmlWarning.java ! test/langtools/jdk/javadoc/tool/6958836/Test.java ! test/langtools/jdk/javadoc/tool/6964914/Test.java ! test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java ! test/langtools/jdk/javadoc/tool/MaxWarns.java ! test/langtools/jdk/javadoc/tool/QuietOption.java ! test/langtools/jdk/javadoc/tool/doclint/DocLintTest.java ! test/langtools/tools/javadoc/6964914/TestStdDoclet.java Changeset: c674ff28c69d Author: ksrini Date: 2018-01-12 10:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c674ff28c69d 8194287: tools/launcher/RunpathTest.java fails with java.lang.NullPointerException 8194286: tools/launcher/FXLauncherTest.java fails with java.lang.UnsatisfiedLinkError Reviewed-by: rriggs ! test/jdk/tools/launcher/FXLauncherTest.java ! test/jdk/tools/launcher/RunpathTest.java Changeset: b95b08f3e1a8 Author: chegar Date: 2018-01-13 16:47 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b95b08f3e1a8 8194883: Unhandleable Push Promises should be cancelled Reviewed-by: dfuchs ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http2Connection.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Stream.java + test/jdk/java/net/httpclient/http2/ImplicitPushCancel.java ! test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java Changeset: b6fc9a193661 Author: mchung Date: 2017-12-21 15:18 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b6fc9a193661 8193767: Improve javadoc in ResourceBundle working with modules Reviewed-by: alanb, naoto ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java Changeset: 9c022c19c960 Author: mchung Date: 2018-01-14 16:42 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9c022c19c960 8191350: jdk/internal/reflect/CallerSensitive/CheckCSMs.java test fails when -Xmx512m set Reviewed-by: alanb ! test/jdk/jdk/internal/reflect/CallerSensitive/CallerSensitiveFinder.java ! test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java Changeset: d52bb1d8ae7b Author: roland Date: 2018-01-15 09:17 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d52bb1d8ae7b 8194914: Compilation fails with "node not on backedge" in OuterStripMinedLoopNode::adjust_strip_mined_loop Summary: Modified assert which is too strong. Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopstripmining/BackedgeNodeWithOutOfLoopControl.java Changeset: 0769bb301c7a Author: roland Date: 2018-01-15 09:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0769bb301c7a 8193597: sun/nio/cs/TestStringCoding.java fails intermittently with getBytes(csn) failed -> GBK Summary: Should not change loop limit check of outer loop. Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopstripmining/LimitSharedwithOutOfLoopTest.java Changeset: b329894ee5a2 Author: roland Date: 2018-01-15 09:21 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b329894ee5a2 8194993: Loop Strip Mining has some leftover debugging code Summary: Removed debugging code. Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp Changeset: 6a5e7a575830 Author: mgronlun Date: 2018-01-15 13:09 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6a5e7a575830 8193933: Export ClassLoaderData claim state to support interleaved object traversal Reviewed-by: coleenp, hseigel ! src/hotspot/share/classfile/classLoaderData.hpp Changeset: 4899ee4eb332 Author: ksrini Date: 2018-01-15 09:23 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4899ee4eb332 8195072: Update ASM 3rd party legal copyright to 6.0 Reviewed-by: vromero ! src/java.base/share/legal/asm.md Changeset: eb5a14ac1e42 Author: asapre Date: 2018-01-16 12:38 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/eb5a14ac1e42 8175542: JMX: Not enough JDP packets received Summary: Fixed test case wrongly reporting timeout failures. Reviewed-by: dholmes, hb Contributed-by: amit.sapre at oracle.com ! test/jdk/ProblemList.txt ! test/jdk/sun/management/jdp/JdpTestCase.java Changeset: a53f30471b2d Author: goetz Date: 2018-01-16 07:48 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a53f30471b2d 8195094: Fix type-O in "8159422: Very high Concurrent Mark mark stack contention" Reviewed-by: tschatzl, dholmes Contributed-by: arno.zeller at sap.com ! src/hotspot/share/memory/allocation.inline.hpp Changeset: 789efc16f4b1 Author: asapre Date: 2018-01-16 20:56 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/789efc16f4b1 8179700: Exceptions thrown in StartManagementAgent.java Summary: Removed Test case entry from problemList.txt Reviewed-by: ysuenaga Contributed-by: amit.sapre at oracle.com ! test/jdk/ProblemList.txt Changeset: 12d9ff9e0a4b Author: rriggs Date: 2018-01-16 10:48 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/12d9ff9e0a4b 8194929: Unreferenced FileDescriptors not closed Reviewed-by: alanb ! make/mapfiles/libjava/mapfile-vers ! test/jdk/java/io/FileInputStream/UnreferencedFISClosesFd.java ! test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java ! test/jdk/java/io/RandomAccessFile/UnreferencedRAFClosesFd.java Changeset: 5f9977540ac9 Author: dfuchs Date: 2018-01-16 19:19 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5f9977540ac9 8195138: The asynchronous Http1HeaderParser doesn't handle all line folds correctly Reviewed-by: chegar ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http1HeaderParser.java ! test/jdk/java/net/httpclient/HeadersTest1.java ! test/jdk/java/net/httpclient/whitebox/Http1HeaderParserTestDriver.java ! test/jdk/java/net/httpclient/whitebox/jdk.incubator.httpclient/jdk/incubator/http/Http1HeaderParserTest.java Changeset: d7995ed9627d Author: lana Date: 2018-01-14 22:25 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d7995ed9627d 8194717: JDK10 L10n resource file update - msgdrop 10 Reviewed-by: joehw Contributed-by: li.jiang at oracle.com ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_es.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_fr.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_it.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ko.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_sv.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/java.base/share/classes/sun/security/tools/keytool/Resources_de.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_es.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_it.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/java.base/share/classes/sun/security/util/Resources_de.java ! src/java.base/share/classes/sun/security/util/Resources_es.java ! src/java.base/share/classes/sun/security/util/Resources_fr.java ! src/java.base/share/classes/sun/security/util/Resources_it.java ! src/java.base/share/classes/sun/security/util/Resources_ja.java ! src/java.base/share/classes/sun/security/util/Resources_ko.java ! src/java.base/share/classes/sun/security/util/Resources_pt_BR.java ! src/java.base/share/classes/sun/security/util/Resources_sv.java ! src/java.base/share/classes/sun/security/util/Resources_zh_CN.java ! src/java.base/share/classes/sun/security/util/Resources_zh_TW.java ! src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/java.desktop/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/java.desktop/share/classes/sun/awt/resources/awt_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_ja.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_ko.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_sv.properties ! src/jdk.compiler/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.compiler/share/classes/sun/tools/serialver/resources/serialver_zh_CN.properties ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_es.properties ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_zh_CN.properties Changeset: 0140779fc556 Author: ljiang Date: 2018-01-14 21:46 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0140779fc556 8187946: Support ISO 4217 Amendments 163 and 164 Reviewed-by: naoto ! make/data/currency/CurrencyData.properties ! src/java.base/share/classes/sun/util/resources/CurrencyNames.properties ! test/jdk/java/util/Currency/ValidateISO4217.java ! test/jdk/java/util/Currency/tablea1.txt ! test/jdk/sun/text/resources/LocaleData ! test/jdk/sun/text/resources/LocaleDataTest.java Changeset: 82c3d4173a53 Author: lana Date: 2018-01-16 22:24 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/82c3d4173a53 Merge ! .hgtags ! make/mapfiles/libjava/mapfile-vers ! src/hotspot/share/classfile/systemDictionary.hpp - src/java.base/share/classes/java/util/ArraysSupport.java - src/java.base/share/native/include/classfile_constants.h ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java - src/java.compiler/share/classes/javax/tools/FileManagerUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java - src/jdk.unsupported/share/classes/sun/reflect/Reflection.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/appcds/UseAppCDS.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java ! test/jdk/ProblemList.txt - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassWithDepth.java - test/jdk/sun/reflect/Reflection/GetCallerClassWithDepth.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java Changeset: 20ed1cebe5f8 Author: weijun Date: 2018-01-17 07:55 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/20ed1cebe5f8 8195119: Fine-tune output text in keytool Reviewed-by: mullan ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java Changeset: 221cf8307606 Author: dl Date: 2018-01-16 18:24 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/221cf8307606 8191483: AbstractQueuedSynchronizer cancel/cancel race Reviewed-by: martin ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! test/jdk/java/util/concurrent/tck/AbstractQueuedSynchronizerTest.java Changeset: 946e34c2dec9 Author: dl Date: 2018-01-16 18:28 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/946e34c2dec9 8193300: Miscellaneous changes imported from jsr166 CVS 2018-01 Reviewed-by: martin ! src/java.base/share/classes/java/util/ArrayList.java ! src/java.base/share/classes/java/util/Vector.java ! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java ! 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/CopyOnWriteArrayList.java ! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/java.base/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! test/jdk/java/util/AbstractCollection/ToString.java ! test/jdk/java/util/AbstractList/CheckForComodification.java ! test/jdk/java/util/AbstractList/FailFastIterator.java ! test/jdk/java/util/AbstractList/HasNextAfterException.java ! test/jdk/java/util/AbstractMap/AbstractMapClone.java ! test/jdk/java/util/AbstractMap/Equals.java ! test/jdk/java/util/AbstractMap/SimpleEntries.java ! test/jdk/java/util/AbstractMap/ToString.java ! test/jdk/java/util/AbstractSequentialList/AddAll.java ! test/jdk/java/util/ArrayList/AddAll.java ! test/jdk/java/util/ArrayList/Bug6533203.java ! test/jdk/java/util/ArrayList/IteratorMicroBenchmark.java ! test/jdk/java/util/ArrayList/RangeCheckMicroBenchmark.java ! test/jdk/java/util/Collection/BiggernYours.java ! test/jdk/java/util/Collection/HotPotatoes.java ! test/jdk/java/util/Collection/IteratorAtEnd.java ! test/jdk/java/util/Collection/IteratorMicroBenchmark.java ! test/jdk/java/util/Collection/RemoveMicroBenchmark.java ! test/jdk/java/util/Collections/AddAll.java ! test/jdk/java/util/Collections/BigBinarySearch.java ! test/jdk/java/util/Collections/BinarySearchNullComparator.java ! test/jdk/java/util/Collections/CheckedIdentityMap.java ! test/jdk/java/util/Collections/CheckedListBash.java ! test/jdk/java/util/Collections/CheckedMapBash.java ! test/jdk/java/util/Collections/CheckedNull.java ! test/jdk/java/util/Collections/CheckedSetBash.java ! test/jdk/java/util/Collections/Disjoint.java ! test/jdk/java/util/Collections/EmptyCollectionSerialization.java ! test/jdk/java/util/Collections/EmptyIterator.java ! test/jdk/java/util/Collections/EmptyNavigableMap.java ! test/jdk/java/util/Collections/EmptyNavigableSet.java ! test/jdk/java/util/Collections/Enum.java ! test/jdk/java/util/Collections/FindSubList.java ! test/jdk/java/util/Collections/Frequency.java ! test/jdk/java/util/Collections/MinMax.java ! test/jdk/java/util/Collections/NCopies.java ! test/jdk/java/util/Collections/NullComparator.java ! test/jdk/java/util/Collections/RacingCollections.java ! test/jdk/java/util/Collections/ReplaceAll.java ! test/jdk/java/util/Collections/ReverseOrder.java ! test/jdk/java/util/Collections/ReverseOrder2.java ! test/jdk/java/util/Collections/Rotate.java ! test/jdk/java/util/Collections/RotateEmpty.java ! test/jdk/java/util/Collections/Ser.java ! test/jdk/java/util/Collections/SetFromMap.java ! test/jdk/java/util/Collections/Swap.java ! test/jdk/java/util/Collections/T5078378.java ! test/jdk/java/util/Collections/T6433170.java ! test/jdk/java/util/Collections/ViewSynch.java ! test/jdk/java/util/Collections/WrappedNull.java ! test/jdk/java/util/HashMap/KeySetRemove.java ! test/jdk/java/util/HashMap/SetValue.java ! test/jdk/java/util/HashMap/ToString.java ! test/jdk/java/util/Hashtable/EqualsCast.java ! test/jdk/java/util/Hashtable/HashCode.java ! test/jdk/java/util/Hashtable/IllegalLoadFactor.java ! test/jdk/java/util/Hashtable/ReadObject.java ! test/jdk/java/util/Hashtable/SelfRef.java ! test/jdk/java/util/IdentityHashMap/ToArray.java ! test/jdk/java/util/IdentityHashMap/ToString.java ! test/jdk/java/util/LinkedHashMap/Basic.java ! test/jdk/java/util/LinkedHashMap/Cache.java ! test/jdk/java/util/LinkedHashMap/EmptyMapIterator.java ! test/jdk/java/util/LinkedHashSet/Basic.java ! test/jdk/java/util/LinkedList/AddAll.java ! test/jdk/java/util/LinkedList/Clone.java ! test/jdk/java/util/LinkedList/ComodifiedRemove.java ! test/jdk/java/util/List/LockStep.java ! test/jdk/java/util/Map/Defaults.java ! test/jdk/java/util/Map/Get.java ! test/jdk/java/util/Map/LockStep.java ! test/jdk/java/util/NavigableMap/LockStep.java ! test/jdk/java/util/PriorityQueue/AddNonComparable.java ! test/jdk/java/util/PriorityQueue/NoNulls.java ! test/jdk/java/util/PriorityQueue/PriorityQueueSort.java ! test/jdk/java/util/PriorityQueue/RemoveContains.java ! test/jdk/java/util/Random/NextBytes.java ! test/jdk/java/util/TimSort/SortPerf.java ! test/jdk/java/util/TreeMap/ContainsValue.java ! test/jdk/java/util/TreeMap/HeadTailTypeError.java ! test/jdk/java/util/TreeMap/NullAtEnd.java ! test/jdk/java/util/TreeMap/NullPermissiveComparator.java ! test/jdk/java/util/TreeMap/SubMap.java ! test/jdk/java/util/TreeMap/SubMapClear.java ! test/jdk/java/util/Vector/ComodifiedRemoveAllElements.java ! test/jdk/java/util/Vector/CopyInto.java ! test/jdk/java/util/Vector/IllegalConstructorArgs.java ! test/jdk/java/util/Vector/LastIndexOf.java ! test/jdk/java/util/Vector/SyncLastIndexOf.java ! test/jdk/java/util/WeakHashMap/GCDuringIteration.java ! test/jdk/java/util/WeakHashMap/Iteration.java ! test/jdk/java/util/WeakHashMap/ZeroInitCap.java ! test/jdk/java/util/concurrent/ArrayBlockingQueue/WhiteBox.java ! test/jdk/java/util/concurrent/BlockingQueue/DrainToFails.java ! test/jdk/java/util/concurrent/BlockingQueue/LoopHelpers.java ! test/jdk/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java ! test/jdk/java/util/concurrent/CompletableFuture/Basic.java ! test/jdk/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java ! test/jdk/java/util/concurrent/ConcurrentHashMap/MapCheck.java ! test/jdk/java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java ! test/jdk/java/util/concurrent/ConcurrentQueues/LoopHelpers.java ! test/jdk/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/jdk/java/util/concurrent/Exchanger/LoopHelpers.java ! test/jdk/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java ! test/jdk/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java ! test/jdk/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/jdk/java/util/concurrent/FutureTask/ExplicitSet.java ! test/jdk/java/util/concurrent/FutureTask/LoopHelpers.java ! test/jdk/java/util/concurrent/FutureTask/NegativeTimeout.java ! test/jdk/java/util/concurrent/LinkedTransferQueue/WhiteBox.java ! test/jdk/java/util/concurrent/atomic/AtomicUpdaters.java ! test/jdk/java/util/concurrent/locks/Lock/LoopHelpers.java ! test/jdk/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java ! test/jdk/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java ! test/jdk/java/util/concurrent/tck/AbstractQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayDeque8Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArrayTest.java ! test/jdk/java/util/concurrent/tck/BlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSetTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubSetTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/jdk/java/util/concurrent/tck/CyclicBarrierTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/jdk/java/util/concurrent/tck/FutureTaskTest.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/MapTest.java ! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/jdk/java/util/concurrent/tck/ThreadLocalRandomTest.java Changeset: 19effb7970bc Author: martin Date: 2018-01-11 20:19 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/19effb7970bc 8194960: Add a test for trust manager and cacerts keystore sanity Reviewed-by: weijun + test/jdk/javax/net/ssl/sanity/CacertsExplorer.java Changeset: 7067fe4e054e Author: goetz Date: 2018-01-16 08:48 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7067fe4e054e 8189102: All tools should support -?, -h and --help Reviewed-by: kvn, jjg, weijun, alanb, rfield, ksrini ! src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/java.base/share/classes/com/sun/java/util/jar/pack/DriverResource.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java ! src/java.rmi/share/classes/sun/rmi/server/resources/rmid.properties ! src/java.scripting/share/classes/com/sun/tools/script/shell/Main.java ! src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties ! src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Options.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.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/jps/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties ! 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/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! 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.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! src/jdk.pack/share/native/unpack200/main.cpp ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Options.properties ! test/jdk/sun/tools/jcmd/TestJcmdDefaults.java ! test/jdk/sun/tools/jcmd/usage.out ! test/jdk/sun/tools/jps/TestJpsSanity.java ! test/jdk/sun/tools/jps/usage.out ! test/jdk/sun/tools/jstat/jstatHelp.sh ! test/jdk/sun/tools/jstat/usage.out ! test/jdk/sun/tools/jstatd/TestJstatdUsage.java + test/jdk/tools/launcher/HelpFlagsTest.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/jdk/javadoc/tool/ToolProviderTest.java ! test/langtools/jdk/jshell/StartOptionTest.java ! test/langtools/tools/javap/InvalidOptions.java ! test/langtools/tools/jdeps/MultiReleaseJar.java Changeset: 050352ed64d5 Author: mchung Date: 2018-01-17 15:17 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/050352ed64d5 8194554: filterArguments runs multiple filters in the wrong order Reviewed-by: psandoz, jrose ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/FilterArgumentsTest.java Changeset: fb978155215d Author: bchristi Date: 2018-01-17 16:15 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fb978155215d 8194879: Runtime.Version parses string which does not conform to spec without throwing IAE Reviewed-by: alanb, iris, rriggs ! src/java.base/share/classes/java/lang/Runtime.java ! test/jdk/java/lang/Runtime/Version/Basic.java Changeset: 707438d2d171 Author: wetmore Date: 2018-01-17 18:26 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/707438d2d171 8190229: Non-ASCII characters in java.security file after 8186093 Reviewed-by: weijun ! src/java.base/share/conf/security/java.security ! src/java.base/share/conf/security/policy/README.txt Changeset: 7537c762d42d Author: jjiang Date: 2018-01-17 18:34 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7537c762d42d 8194864: Outputs more details for PKCS11 tests if the NSS lib version cannot be determined Summary: It outputs the lib content if the lib version cannot be parsed Reviewed-by: xuelei ! test/jdk/ProblemList.txt ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: 0dec8c41170c Author: jjiang Date: 2018-01-17 20:07 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0dec8c41170c 8195667: ProblemList PKCS11 tests Secmod/AddTrustedCert.java and tls/TestKeyMaterial.java due to JDK-8180837 Summary: Puts sun/security/pkcs11/Secmod/AddTrustedCert.java and sun/security/pkcs11/tls/TestKeyMaterial.java into ProblemList Reviewed-by: weijun ! test/jdk/ProblemList.txt Changeset: db044d7e9885 Author: mcimadamore Date: 2018-01-18 11:46 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/db044d7e9885 8195598: Reference to overloaded method is ambiguous with 3 methods but works with 2 Summary: Pertinent to applicability bit set on argument expression even if only one method is not pertinent Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/langtools/tools/javac/lambda/T8195598.java Changeset: 5840ed767456 Author: joehw Date: 2018-01-16 14:44 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5840ed767456 8181047: Add comment to technical terms that shall not be translated Reviewed-by: lancea, ljiang ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.properties Changeset: 9cf44c40aa35 Author: darcy Date: 2018-01-16 17:27 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9cf44c40aa35 8189146: Have use of "var" in 9 and earlier source versions issue a warning for type declarations Reviewed-by: mcimadamore, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/diags/examples/FutureVarNotAllowed.java ! test/langtools/tools/javac/lvti/ParserTest.java ! test/langtools/tools/javac/lvti/ParserTest.out + test/langtools/tools/javac/lvti/ParserTest9.out Changeset: f94706337b07 Author: ksrini Date: 2018-01-16 19:26 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f94706337b07 8194953: doclet corrupts HTML files when adding navbar Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java ! test/langtools/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java + test/langtools/jdk/javadoc/doclet/testCopyFiles/packages/p2/Foo.java + test/langtools/jdk/javadoc/doclet/testCopyFiles/packages/p2/doc-files/case1.html + test/langtools/jdk/javadoc/doclet/testCopyFiles/packages/p2/doc-files/case2.html + test/langtools/jdk/javadoc/doclet/testCopyFiles/packages/p2/doc-files/case3.html + test/langtools/jdk/javadoc/doclet/testCopyFiles/packages/p2/doc-files/case4.html Changeset: fe2950b07f1e Author: simonis Date: 2018-01-17 17:26 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fe2950b07f1e 8195153: [test] runtime/6981737/Test6981737.java shouldn't check 'java.vendor' and 'java.vm.vendor' properties Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/6981737/Test6981737.java Changeset: 592e22777742 Author: msheppar Date: 2017-09-03 16:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/592e22777742 8160104: CORBA communication improvements Reviewed-by: rriggs, dfuchs ! src/java.base/share/conf/security/java.security ! src/java.corba/share/classes/com/sun/corba/se/impl/encoding/BufferManagerWriteGrow.java ! src/java.corba/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java + src/java.corba/share/classes/com/sun/corba/se/impl/ior/IORTypeCheckRegistryImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/orb/ORBSingleton.java + src/java.corba/share/classes/com/sun/corba/se/spi/ior/IORTypeCheckRegistry.java ! src/java.corba/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: 9c56c953d8db Author: hseigel Date: 2017-03-20 13:05 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9c56c953d8db 8175932: Improve host instance supports Reviewed-by: coleenp, mschoene Contributed-by: harold.seigel at oracle.com ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: d44d912ea9bb Author: rprotacio Date: 2017-05-25 15:39 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d44d912ea9bb 8180020: Improve SymbolHashMap entry handling Reviewed-by: mschoene, coleenp, rhalade Contributed-by: rachel.protacio at oracle.com ! src/hotspot/share/oops/constantPool.hpp Changeset: 2e867226b914 Author: vlivanov Date: 2017-05-26 18:39 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2e867226b914 8174962: Better interface invocations Reviewed-by: jrose, coleenp, ahgross, acorn, iignatyev ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/arm/vtableStubs_arm.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.hpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/sparc/templateTable_sparc.cpp ! src/hotspot/cpu/sparc/vtableStubs_sparc.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/vtableStubs_x86_32.cpp ! src/hotspot/cpu/x86/vtableStubs_x86_64.cpp ! src/hotspot/share/aot/aotCompiledMethod.cpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/oops/compiledICHolder.cpp ! src/hotspot/share/oops/compiledICHolder.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CompiledICHolder.java + test/hotspot/gtest/code/test_vtableStub.cpp + test/hotspot/jtreg/runtime/RedefineTests/RedefineInterfaceCall.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformTestCommon.java Changeset: b2b67c8fc91a Author: rprotacio Date: 2017-06-12 13:58 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b2b67c8fc91a 8181664: Improve JVM UTF String handling Reviewed-by: mschoene, coleenp, rhalade, acorn, gtriantafill Contributed-by: rachel.protacio at oracle.com ! src/hotspot/share/prims/jni.cpp Changeset: 607d78d0e6f7 Author: psadhukhan Date: 2017-03-23 10:52 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/607d78d0e6f7 8176450: Revise default document styling Reviewed-by: prr, serb, mschoene ! src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java Changeset: 46e99460e8c9 Author: apetcher Date: 2017-04-28 10:17 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/46e99460e8c9 8172525: Improve key keying case Reviewed-by: mullan, valeriep, rhalade, ahgross ! src/java.base/share/classes/com/sun/crypto/provider/DESKey.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeKey.java ! src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java ! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java Changeset: f6796a7e4454 Author: prr Date: 2017-05-17 14:52 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f6796a7e4454 8179533: Cleaner print job handling Reviewed-by: serb, mschoene, rhalade ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp Changeset: 592c141b1ca3 Author: prr Date: 2017-05-17 14:57 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/592c141b1ca3 8180011: Cleaner native graphics device handling Reviewed-by: serb, mschoene, rhalade ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DGraphicsDevice.cpp Changeset: d3d2db0f234f Author: serb Date: 2017-05-17 18:22 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d3d2db0f234f 8179990: Cleaner palette entry handling Reviewed-by: prr, mschoene, rhalade ! src/java.desktop/windows/native/libawt/windows/awt_Palette.cpp Changeset: 1fc3a5f9791f Author: serb Date: 2017-06-01 15:15 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1fc3a5f9791f 8180015: Cleaner AWT robot handling Reviewed-by: prr, mschoene, rhalade ! src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp Changeset: 871b8bb201ea Author: jlaskey Date: 2017-06-05 12:36 -0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/871b8bb201ea 8180869: Cleaner image file reading handling Reviewed-by: ahgross, rriggs, rhalade Contributed-by: james.laskey at oracle.com ! src/java.base/share/native/libjimage/imageFile.cpp ! src/java.base/share/native/libjimage/imageFile.hpp Changeset: 6c986cf7299a Author: prr Date: 2017-06-29 11:53 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6c986cf7299a 8180877: More deeply colored ICC spaces Reviewed-by: serb, rhalade, mschoene ! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: c4de888db380 Author: apetcher Date: 2017-07-04 01:52 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c4de888db380 8174756: Extra validation for public keys Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java Changeset: 0255315ac8d4 Author: vtewari Date: 2017-07-23 10:33 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0255315ac8d4 8182125: Improve reliability of DNS lookups Reviewed-by: chegar, rriggs, dfuchs ! src/java.base/share/classes/module-info.java + src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DNSDatagramSocketFactory.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/ResourceRecord.java Changeset: 950cb68f9d82 Author: apetcher Date: 2017-07-28 18:20 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/950cb68f9d82 8182387: Improve PKCS usage Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/util/DerValue.java Changeset: 9baae459d58e Author: naoto Date: 2017-08-08 10:43 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9baae459d58e 8182601: Improve usage messages Reviewed-by: alanb, ahgross, ksrini, mchung ! src/java.base/share/classes/java/util/ResourceBundle.java Changeset: cd23d1f99660 Author: valeriep Date: 2017-08-24 19:18 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cd23d1f99660 8186212: Improve GSS handling Reviewed-by: weijun, ahgross ! src/java.security.jgss/share/native/libj2gss/GSSLibStub.c Changeset: 1820a65c4e59 Author: valeriep Date: 2017-08-31 21:44 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1820a65c4e59 8178466: Better RSA parameters Reviewed-by: mullan, ahgross ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java Changeset: e6b173e04545 Author: vinnie Date: 2017-09-04 19:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e6b173e04545 8178449: Improve LDAP logins Reviewed-by: mullan, asmotrak ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java Changeset: 96bff87ea130 Author: vinnie Date: 2017-09-05 15:53 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/96bff87ea130 8181670: Improve implementation of keystores Reviewed-by: mullan ! src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Changeset: 2ce508de5c77 Author: weijun Date: 2017-09-14 07:45 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2ce508de5c77 8178458: Better use of certificates in LDAP Reviewed-by: vinnie, asmotrak ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java Changeset: b0ab05328879 Author: uvangapally Date: 2017-09-25 19:44 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b0ab05328879 8186998: Improve JMX supportive features Summary: Improve JMX supportive features Reviewed-by: mchung, dfuchs, rriggs, hb, skoivu, rhalade ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java ! src/jdk.management.agent/share/classes/sun/management/jmxremote/SingleEntryRegistry.java ! test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Changeset: 8dff65f1d611 Author: joehw Date: 2017-10-04 10:33 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8dff65f1d611 8186080: Transform XML interfaces Reviewed-by: dfuchs, lancea, rriggs ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDynamic.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/Extensions.java - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/Translet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/TransletOutputHandlerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TrAXFilter.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/DTMManager.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMManagerDefault.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/AttList.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/CachedXPathAPI.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPathAPI.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPathContext.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathImplUtil.java ! src/java.xml/share/classes/javax/xml/transform/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/transform/TransformerFactory.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactory.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactoryFinder.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactory.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryFinder.java ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlFeatures.java ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java ! test/jaxp/javax/xml/jaxp/unittest/common/Bug6941169Test.java Changeset: 2f2d159b03fc Author: serb Date: 2017-10-02 11:04 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2f2d159b03fc 8185325: Improve GTK initialization Reviewed-by: azvegint, rhalade, mschoene ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: 52449da2c349 Author: weijun Date: 2017-10-18 10:43 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/52449da2c349 8186600: Improve property negotiations Reviewed-by: valeriep, ahgross, mullan ! src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/LoginConfigImpl.java Changeset: d4898fde8171 Author: apetcher Date: 2017-10-24 09:58 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d4898fde8171 8185292: Stricter key generation Reviewed-by: mullan ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/java.base/share/lib/security/default.policy ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/DHGenSecretKey.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement2.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/SameDHKeyStressTest.java ! test/jdk/sun/security/pkcs11/KeyAgreement/TestDH.java Changeset: 0786897e86b3 Author: xuelei Date: 2017-10-31 00:54 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0786897e86b3 8163237: Restrict the use of EXPORT cipher suites Reviewed-by: mullan, igerasim, rhalade, jnimeh ! src/java.base/share/conf/security/java.security ! test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java Changeset: 02176e56d91c Author: weijun Date: 2017-11-04 08:56 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/02176e56d91c 8186606: Improve LDAP lookup robustness Reviewed-by: mullan, skoivu, ahgross ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java Changeset: 02cc6b9c271d Author: weijun Date: 2017-11-06 22:09 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/02cc6b9c271d 8190789: sun/security/provider/certpath/LDAPCertStore/TestURICertStoreParameters.java fails after JDK-8186606 Reviewed-by: mullan ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java Changeset: 6cc53a4de27e Author: serb Date: 2017-11-06 10:24 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6cc53a4de27e 8190289: More refactoring for client deserialization cases Reviewed-by: prr, azvegint, rhalade, skoivu ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java Changeset: d9fcb7ba8133 Author: mdoerr Date: 2017-11-28 01:08 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d9fcb7ba8133 8191907: PPC64 and s390 parts of JDK-8174962: Better interface invocations Reviewed-by: goetz ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/ppc/vtableStubs_ppc_64.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/s390/vtableStubs_s390.cpp Changeset: 8877e857fdd7 Author: smarks Date: 2017-11-27 17:30 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8877e857fdd7 8189284: More refactoring for deserialization cases Reviewed-by: rriggs, igerasim, rhalade, skoivu ! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java Changeset: f2e87b6383af Author: vtewari Date: 2017-11-29 13:56 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f2e87b6383af 8191142: More refactoring for naming deserialization cases Reviewed-by: chegar, rriggs ! src/java.naming/share/classes/javax/naming/directory/BasicAttributes.java Changeset: dda1a427b086 Author: xuelei Date: 2017-12-19 16:31 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/dda1a427b086 8193683: Increase the number of clones in the CloneableDigest Reviewed-by: coffeys, wetmore ! src/java.base/share/classes/sun/security/ssl/HandshakeHash.java Changeset: 97db4ee6e59a Author: asaha Date: 2018-01-08 21:55 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/97db4ee6e59a Merge Changeset: 0d3b030b3eb7 Author: asaha Date: 2018-01-12 15:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0d3b030b3eb7 Merge - src/java.compiler/share/classes/javax/lang/model/overview.html - src/java.compiler/share/classes/javax/tools/overview.html - src/jdk.jdeps/share/classes/com/sun/tools/javap/overview.html - test/langtools/tools/javac/T8192885/AddGotoAfterForLoopToLNTTest.java Changeset: ca245f9f70db Author: asaha Date: 2018-01-17 07:09 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ca245f9f70db Merge ! src/java.base/share/classes/java/util/ResourceBundle.java Changeset: ef70df777355 Author: asaha Date: 2018-01-17 17:33 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ef70df777355 Merge Changeset: fca88bbbafb9 Author: psandoz Date: 2017-12-21 13:52 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fca88bbbafb9 8075939: Stream.flatMap() causes breaking of short-circuiting of terminal operations Reviewed-by: forax, smarks ! src/java.base/share/classes/java/util/stream/DoublePipeline.java ! src/java.base/share/classes/java/util/stream/IntPipeline.java ! src/java.base/share/classes/java/util/stream/LongPipeline.java ! src/java.base/share/classes/java/util/stream/ReferencePipeline.java ! src/java.base/share/classes/java/util/stream/SortedOps.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java Changeset: 4e4929530412 Author: hannesw Date: 2018-01-17 22:44 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4e4929530412 8195123: Very large regressions in Octane benchmarks using 10-b39 Reviewed-by: jlaskey, attila ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java Changeset: 5d699d81c10c Author: dlong Date: 2018-01-17 14:25 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5d699d81c10c 8194988: 8 Null pointer dereference defect groups related to MultiNode::proj_out() Reviewed-by: kvn ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/divnode.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/multnode.cpp ! src/hotspot/share/opto/multnode.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/stringopts.cpp Changeset: 860326263d1f Author: vlivanov Date: 2018-01-18 02:25 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/860326263d1f 8194963: SystemDictionary::link_method_handle_constant() can't link MethodHandle.invoke()/invokeExact() Reviewed-by: kvn, psandoz ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmSymbols.hpp Changeset: b6bb930cd488 Author: darcy Date: 2018-01-17 17:53 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b6bb930cd488 8191839: ModuleElement.DirectiveVisitor :: visit???() method behavior is deviating from the spec Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java Changeset: c7eea4b541d1 Author: simonis Date: 2018-01-18 03:12 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c7eea4b541d1 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag Reviewed-by: erikj, dholmes ! make/autoconf/generated-configure.sh ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/native/libjava/System.c Changeset: 2a6c704c1574 Author: mli Date: 2018-01-18 11:48 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2a6c704c1574 8195478: sun/text/resources/LocaleDataTest.java fails with java.lang.Exception Reviewed-by: naoto, rgoel ! test/jdk/sun/text/resources/LocaleData ! test/jdk/sun/text/resources/LocaleDataTest.java Changeset: 256f31c1e051 Author: mbaesken Date: 2018-01-17 15:30 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/256f31c1e051 8195615: libsplashscreen linux ppc64le build error after libpng update Reviewed-by: prr, mdoerr ! src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Changeset: 391502ceeed9 Author: goetz Date: 2018-01-18 10:26 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/391502ceeed9 8194869: [TESTBUG][aix, s390] Adapt tests to platforms. Reviewed-by: mbaesken, simonis, dholmes, serb ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/OS.java ! test/jdk/java/awt/FontClass/CreateFont/fileaccess/TestFontFile.sh ! test/jdk/java/awt/JAWT/JAWT.sh ! test/jdk/java/awt/Toolkit/AutoShutdown/EventQueuePush/EventQueuePushAutoshutdown.sh ! test/jdk/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/jdk/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh ! test/jdk/sun/security/mscapi/ShortRSAKey1024.sh ! test/jdk/sun/security/pkcs11/PKCS11Test.java ! test/jdk/sun/security/tools/keytool/i18n.sh Changeset: 6481320bb72c Author: lana Date: 2018-01-18 16:20 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6481320bb72c Added tag jdk-10+40 for changeset 860326263d1f ! .hgtags Changeset: e5da6c246176 Author: dlong Date: 2018-01-18 10:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e5da6c246176 8194992: Null pointer dereference in MultiNode::proj_out related to loopexit() Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/superword.cpp Changeset: 37a5a1109b93 Author: dlong Date: 2018-01-18 10:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/37a5a1109b93 8194989: 2 Null pointer dereference defect groups caused by Dependencies::DepValue::as_klass() Reviewed-by: kvn ! src/hotspot/share/code/dependencies.hpp Changeset: 00d8c8d696e9 Author: dlong Date: 2018-01-18 10:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/00d8c8d696e9 8194991: Null pointer dereference caused by c2v_getNextStackFrame Reviewed-by: kvn ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Changeset: be259687afab Author: dlong Date: 2018-01-18 10:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/be259687afab 8194982: 2 Null pointer dereference defect groups related to ProjNode::is_uncommon_trap_if_pattern() Reviewed-by: kvn ! src/hotspot/share/opto/ifnode.cpp Changeset: 7fc3d62481ba Author: never Date: 2018-01-18 09:01 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7fc3d62481ba 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects Reviewed-by: kvn, sspitsyn, phh ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/runtime/vframe_hp.cpp ! src/hotspot/share/runtime/vframe_hp.hpp Changeset: 1dab70e20292 Author: lana Date: 2018-01-18 18:58 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1dab70e20292 Merge ! .hgtags ! make/autoconf/generated-configure.sh ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/sparc/templateTable_sparc.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/runtime/arguments.cpp - src/java.base/share/classes/java/util/ArraysSupport.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/conf/security/java.security - src/java.base/share/native/include/classfile_constants.h ! src/java.base/share/native/libjava/System.c - src/java.compiler/share/classes/javax/tools/FileManagerUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java - src/jdk.unsupported/share/classes/sun/reflect/Reflection.java - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassWithDepth.java - test/jdk/sun/reflect/Reflection/GetCallerClassWithDepth.java ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: be4d948d1299 Author: mli Date: 2018-01-19 15:21 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/be4d948d1299 8194284: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails with java.lang.RuntimeException: CheckRegisterInLog got exception timeout 6480000ms out of range Reviewed-by: dholmes, rriggs ! test/jdk/java/rmi/testlibrary/RMID.java ! test/jdk/java/rmi/testlibrary/TestLibrary.java Changeset: a587f95313f1 Author: jlahoda Date: 2018-01-19 17:11 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a587f95313f1 8191842: JShell: Inferred type information is lost when assigning types to a \"var\" Summary: For vars, upgrading all anonymous classes to member classes; stripping intersection types from fields before writing. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java ! src/jdk.jshell/share/classes/jdk/jshell/Util.java ! src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java ! test/langtools/jdk/jshell/InaccessibleExpressionTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/jdk/jshell/TypeNameTest.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: 4d7a4fad8190 Author: ccheung Date: 2018-01-04 22:47 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4d7a4fad8190 8192927: os::dir_is_empty is incorrect on Windows Summary: Check file names in a directory. It is empty if only the "." and ".." files exist. Use unicode version of windows APIs to handle long path. Reviewed-by: iklam, sspitsyn ! src/hotspot/os/windows/os_windows.cpp ! test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java Changeset: 9e524244b67d Author: jwilhelm Date: 2018-01-05 22:02 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9e524244b67d Merge - make/langtools/intellij/runConfigurations/javah.xml - make/langtools/test/bootstrap/javah.sh - make/langtools/test/lib/javah.sh ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/thread.cpp - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! test/hotspot/jtreg/ProblemList.txt - test/jdk/java/net/httpclient/RequestProcessorExceptions.java Changeset: d8bdf14c4f1e Author: eosterlund Date: 2018-01-08 13:13 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d8bdf14c4f1e 8191888: Refactor ClassLoaderData::remove_handle to use the Access API Reviewed-by: tschatzl, pliden, coleenp ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: c39ae979ca35 Author: eosterlund Date: 2018-01-08 13:22 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c39ae979ca35 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. Reviewed-by: dholmes, rkennke, tschatzl ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 31cd0c16f4d2 Author: eosterlund Date: 2018-01-08 15:09 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/31cd0c16f4d2 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API Reviewed-by: kbarrett, coleenp ! src/hotspot/share/prims/resolvedMethodTable.cpp ! src/hotspot/share/prims/resolvedMethodTable.hpp Changeset: 80239a242d34 Author: eosterlund Date: 2018-01-08 15:12 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/80239a242d34 8191894: Refactor weak references in JvmtiTagHashmap to use the Access API Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/prims/jvmtiTagMap.cpp Changeset: 01b07229a6ad Author: dcubed Date: 2018-01-08 09:58 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/01b07229a6ad 8194652: VMError::print_native_stack() is missing an os::is_first_C_frame() check Reviewed-by: fparain, gthornbr, stuefe ! src/hotspot/share/utilities/vmError.cpp + test/hotspot/jtreg/runtime/ErrorHandling/BadNativeStackInErrorHandlingTest.java Changeset: 688e5cbd0b91 Author: eosterlund Date: 2018-01-08 16:21 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/688e5cbd0b91 8192003: Refactor weak references in StringTable to use the Access API Reviewed-by: pliden, dholmes, coleenp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/stringTable.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 1703d83b3ffe Author: coleenp Date: 2018-01-08 09:46 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1703d83b3ffe 8058259: compute_offset() is confusing for static fields Summary: remove most hard-coded offsets, have compute_offset function that takes a string and creates a TempNewSymbol, have static_field_addr() not add in InstanceMirrorKlass::offset_of_static_fields, ie use offset from find_field Reviewed-by: kbarrett, sspitsyn ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/jvmci/jvmciJavaClasses.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/init.cpp Changeset: 7f97d35fac6e Author: coleenp Date: 2018-01-08 12:02 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7f97d35fac6e Merge ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp Changeset: 77797298bf36 Author: ecaspole Date: 2018-01-08 17:47 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/77797298bf36 8192857: LogCompilation could show the intrinsics more like +PrintIntrinsics Summary: Show the intrinsics internal name in the inlining output Reviewed-by: kvn, gtriantafill ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/CallSite.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java Changeset: a92a5a71364a Author: dpochepk Date: 2018-01-09 18:18 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a92a5a71364a 8194256: AARCH64: SIMD shift instructions are incorrectly encoded Reviewed-by: aph ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp Changeset: b1006bbb925a Author: dtitov Date: 2018-01-09 09:51 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b1006bbb925a 8187448: 360 doc issues in jdwp-protocol.html Reviewed-by: sspitsyn, amenkov ! make/data/jdwp/jdwp.spec ! make/jdk/src/classes/build/tools/jdwpgen/AbstractCommandNode.java ! make/jdk/src/classes/build/tools/jdwpgen/AbstractNamedNode.java ! make/jdk/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java ! make/jdk/src/classes/build/tools/jdwpgen/CommandSetNode.java ! make/jdk/src/classes/build/tools/jdwpgen/ConstantSetNode.java ! make/jdk/src/classes/build/tools/jdwpgen/ErrorSetNode.java ! make/jdk/src/classes/build/tools/jdwpgen/RootNode.java Changeset: 5f86c562a39e Author: ctornqvi Date: 2018-01-09 16:52 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5f86c562a39e 8194636: Apply CONCURRENCY_FACTOR to max value in concurrency calculation Reviewed-by: erikj ! test/hotspot/jtreg/Makefile Changeset: d09be0adcf78 Author: jcbeyler Date: 2017-12-19 20:14 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d09be0adcf78 8191985: JDK-8190862 work for arch arm Summary: Fixed Interpreter never refills TLAB Reviewed-by: dsamersoff, aph ! src/hotspot/cpu/arm/templateTable_arm.cpp Changeset: 9f6f48d4f9a1 Author: goetz Date: 2018-01-09 08:38 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9f6f48d4f9a1 8194814: [ppc, s390] A row of minor fixes and cleanups Summary: Fix the data types of pd flags. Reviewed-by: mdoerr ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_globals_ppc.hpp ! src/hotspot/cpu/ppc/c2_globals_ppc.hpp ! src/hotspot/cpu/ppc/c2_init_ppc.cpp ! src/hotspot/cpu/ppc/globals_ppc.hpp ! src/hotspot/cpu/ppc/icache_ppc.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/jniFastGetField_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/cpu/ppc/runtime_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/stubRoutines_ppc_64.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/s390/bytes_s390.hpp ! src/hotspot/cpu/s390/c1_globals_s390.hpp ! src/hotspot/cpu/s390/c2_globals_s390.hpp ! src/hotspot/cpu/s390/globals_s390.hpp Changeset: bf12b502df94 Author: tschatzl Date: 2018-01-10 10:21 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/bf12b502df94 8194824: Add gc/stress/gclocker/TestGCLockerWithParallel.java to the ProblemList file Reviewed-by: ehelin, kbarrett ! test/hotspot/jtreg/ProblemList.txt Changeset: 69d65d9dcadb Author: eosterlund Date: 2018-01-10 18:04 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/69d65d9dcadb 8193063: Enabling narrowOop values for RawAccess accesses Reviewed-by: pliden, kbarrett ! src/hotspot/share/gc/g1/g1SATBCardTableModRefBS.inline.hpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/access.inline.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/oops/accessBackend.inline.hpp Changeset: a58c1924e037 Author: gadams Date: 2018-01-09 13:58 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a58c1924e037 6640188: Methods com.cun.attach.VirtualMachine.load... don't throw NullPointerxception Reviewed-by: sspitsyn ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java Changeset: fdef4da95080 Author: jgeorge Date: 2018-01-11 11:35 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fdef4da95080 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands Summary: Test for the clhsdb 'thread' and 'threads' commands. Avoids an incorrect 'Couldn't find thread -a' being printed. Reviewed-by: sspitsyn, sballal ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java + test/hotspot/jtreg/serviceability/sa/ClhsdbThread.java Changeset: 862c41cf1c7f Author: tschatzl Date: 2018-01-11 10:40 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/862c41cf1c7f 8137099: G1 needs to "upgrade" GC within the safepoint if it can't allocate during that safepoint to avoid OoME Summary: During a minor GC, if memory allocation fails, start a full GC within the same VM operation in the same safepoint. This avoids a race where the GC locker can prevent the full GC from occurring, and a premature OoME. Reviewed-by: ehelin, sjohanss, phh Contributed-by: thomas.schatzl at oracle.com, axel.siebenborn at sap.com ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/vm_operations_g1.cpp ! src/hotspot/share/gc/g1/vm_operations_g1.hpp ! src/hotspot/share/runtime/vm_operations.hpp ! test/hotspot/jtreg/ProblemList.txt + test/hotspot/jtreg/gc/stress/TestJNIBlockFullGC/TestJNIBlockFullGC.java + test/hotspot/jtreg/gc/stress/TestJNIBlockFullGC/libTestJNIBlockFullGC.c Changeset: a8ab9344dab6 Author: tschatzl Date: 2018-01-11 11:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a8ab9344dab6 8180280: [TESTBUG] Test for JDK-8180048 Summary: Add test at is executed only at higher tiers to allow more time for execution. Reviewed-by: kbarrett, eosterlund + test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java Changeset: 2569f227ae8e Author: tschatzl Date: 2018-01-11 11:28 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2569f227ae8e 8129440: G1 crash during concurrent root region scan Summary: Make concurrent memory accesses to oops on the heap volatile to avoid reloading by the compiler duplicating oop loading code. Reviewed-by: ehelin, eosterlund ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp Changeset: ec666229de1f Author: dstewart Date: 2018-01-11 20:25 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ec666229de1f 8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" Reviewed-by: dholmes, zgu ! test/hotspot/jtreg/runtime/NMT/PrintNMTStatistics.java Changeset: 612dfa1d8aad Author: coleenp Date: 2018-01-11 18:42 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/612dfa1d8aad 8130039: Move the platform-specific [OS]Semaphore code 8130038: Unify the semaphore usage in os_xxx.cpp 8194763: os::signal_lookup is unused Reviewed-by: dholmes, kbarrett ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp + src/hotspot/os/bsd/semaphore_bsd.cpp ! src/hotspot/os/bsd/semaphore_bsd.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/os_posix.cpp + src/hotspot/os/posix/semaphore_posix.cpp ! src/hotspot/os/posix/semaphore_posix.hpp ! src/hotspot/os/solaris/os_solaris.cpp ! src/hotspot/os/windows/os_windows.cpp + src/hotspot/os/windows/semaphore_windows.cpp ! src/hotspot/share/runtime/os.hpp Changeset: b96f03796580 Author: coleenp Date: 2018-01-11 21:49 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b96f03796580 Merge Changeset: 7bba05746c44 Author: jwilhelm Date: 2018-01-13 02:56 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7bba05746c44 Merge ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 01094f78d990 Author: ehelin Date: 2018-01-17 19:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/01094f78d990 8195158: Concurrent System.gc() is "upgraded" to stop-the-world System.gc() Reviewed-by: sjohanss, eosterlund ! src/hotspot/share/gc/g1/vm_operations_g1.cpp + test/hotspot/jtreg/gc/g1/TestConcurrentSystemGC.java Changeset: 96ef7a0cf0b1 Author: kaddepalli Date: 2017-12-20 18:08 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/96ef7a0cf0b1 8190281: Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java Reviewed-by: psadhukhan, serb, ssadetsky ! src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java Changeset: 42ad9a781f51 Author: sveerabhadra Date: 2017-12-22 11:00 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/42ad9a781f51 8190192: Double click on the title bar no longer repositions the window Reviewed-by: serb, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/jdk/java/awt/Window/WindowResizing/DoubleClickTitleBarTest.java Changeset: 35b5da568499 Author: jdv Date: 2017-12-26 13:38 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/35b5da568499 8190997: PNGImageReader throws NullPointerException when PLTE section is missing Reviewed-by: serb, bpb, pnarayanan ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java + test/jdk/javax/imageio/plugins/png/PngPLTEChunkMissingTest.java Changeset: 219585efb03c Author: prr Date: 2018-01-08 08:53 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/219585efb03c Merge - make/langtools/intellij/runConfigurations/javah.xml - make/langtools/test/bootstrap/javah.sh - make/langtools/test/lib/javah.sh - src/java.base/share/classes/java/util/ArraysSupport.java - src/java.base/share/native/include/classfile_constants.h - src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CooperativePhaseTest.java - test/jdk/java/net/httpclient/RequestProcessorExceptions.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java - test/langtools/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out Changeset: 2ea3667af41d Author: jdv Date: 2018-01-10 12:45 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/2ea3667af41d 8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image Reviewed-by: bpb, pnarayanan ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java + test/jdk/javax/imageio/plugins/jpeg/JpegTablesOnlyReadTest.java Changeset: f611f49a46c9 Author: pnarayanan Date: 2018-01-16 10:49 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f611f49a46c9 8194489: Incorrect size computation at BandedSampleModel.createDataBuffer() Reviewed-by: bpb, jdv Contributed-by: prahalad.kumar.narayanan at oracle.com ! src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java + test/jdk/java/awt/image/BandedSampleModel/BandedSampleModelSizeTest.java Changeset: 6cfee3ad7a76 Author: jdv Date: 2018-01-17 10:58 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6cfee3ad7a76 8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Reviewed-by: serb, bpb, pnarayanan ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java + test/jdk/javax/imageio/plugins/png/PngReaderLargeWidthStrideTest.java Changeset: 36a1966132aa Author: prr Date: 2018-01-17 09:08 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/36a1966132aa Merge - src/java.compiler/share/classes/javax/lang/model/overview.html - src/java.compiler/share/classes/javax/tools/FileManagerUtils.java - src/java.compiler/share/classes/javax/tools/overview.html - src/jdk.jdeps/share/classes/com/sun/tools/javap/overview.html - src/jdk.unsupported/share/classes/sun/reflect/Reflection.java - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassWithDepth.java - test/jdk/sun/reflect/Reflection/GetCallerClassWithDepth.java - test/langtools/tools/javac/T8192885/AddGotoAfterForLoopToLNTTest.java Changeset: e4b03365ddbf Author: jdv Date: 2018-01-18 11:22 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e4b03365ddbf 8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Reviewed-by: prr, ceisserer, pnarayanan ! src/java.desktop/unix/classes/sun/java2d/xr/XRSolidSrcPict.java + test/jdk/java/awt/Color/XRenderTranslucentColorDrawTest.java Changeset: 371c6d66d2ec Author: prr Date: 2018-01-19 09:32 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/371c6d66d2ec Merge - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6a014a1e8d2b Author: jlahoda Date: 2018-01-19 21:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6a014a1e8d2b 8195789: Building of test/langtools/jdk/jshell/VariablesTest.java may fail Summary: Adding proper @modules tag. Reviewed-by: vromero ! test/langtools/jdk/jshell/VariablesTest.java Changeset: e7164f73c4d3 Author: goetz Date: 2018-01-19 15:05 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e7164f73c4d3 8195663: Java launcher HelpFlagsTest.java fails with java.lang.AssertionError Reviewed-by: ksrini, dholmes ! test/jdk/tools/launcher/HelpFlagsTest.java Changeset: 67abfee27e69 Author: weijun Date: 2018-01-22 12:00 +0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/67abfee27e69 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 Reviewed-by: mullan ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! src/java.security.jgss/share/classes/sun/security/krb5/EncryptedData.java ! src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsReq.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes128CtsHmacSha2EType.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes128Sha2.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes256CtsHmacSha2EType.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes256Sha2.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/EType.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/HmacSha2Aes128CksumType.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/HmacSha2Aes256CksumType.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/AesSha2DkCrypto.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java ! test/jdk/sun/security/krb5/auto/BasicKrb5Test.java ! test/jdk/sun/security/krb5/auto/KDC.java ! test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/jdk/sun/security/krb5/etype/ETypeOrder.java + test/jdk/sun/security/krb5/etype/KerberosAesSha2.java Changeset: 7c03f19d38a7 Author: aph Date: 2018-01-19 16:57 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7c03f19d38a7 8195685: AArch64: AArch64 cannot build with JDK-8174962 Reviewed-by: adinn, njian ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp Changeset: 89111a0e6355 Author: sundar Date: 2018-01-22 20:31 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/89111a0e6355 8195829: Parsing a nameless ES6 class results in a thrown NullPointerException. Reviewed-by: jlaskey, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/IRTranslator.java + test/nashorn/script/basic/JDK-8195829.js Changeset: 36f58bd6269f Author: jjg Date: 2018-01-22 11:15 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/36f58bd6269f 8195796: Reduce the size of relative URLs in generated docs Reviewed-by: 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/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocLink.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPath.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java ! test/langtools/jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java ! test/langtools/jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testClassLinks/TestClassLinks.java ! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java ! test/langtools/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/langtools/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java + test/langtools/jdk/javadoc/doclet/testDocPaths/TestDocPaths.java ! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java ! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testInlineLinkLabel/TestInlineLinkLabel.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/langtools/jdk/javadoc/doclet/testNestedGenerics/TestNestedGenerics.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/langtools/jdk/javadoc/doclet/testOrdering/TestOrdering.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestMultiInheritance.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenMethodDocCopy.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPackageFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPrivateFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java ! test/langtools/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java ! test/langtools/jdk/javadoc/doclet/testThrowsTag/TestThrowsTag.java ! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/langtools/jdk/javadoc/doclet/testTypeVariableLinks/TestTypeVariableLinks.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/langtools/jdk/javadoc/doclet/testWarnings/TestWarnings.java Changeset: e1876e6b57b6 Author: jjg Date: 2018-01-22 11:28 -0800 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e1876e6b57b6 8195805: Doclet incorrectly updates all attributes in tags when relocating links Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java From frederic.parain at oracle.com Tue Jan 23 21:25:06 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 23 Jan 2018 16:25:06 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: Hi John, thank you for the detailed feedback. The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying way for class files to express their expectations regarding types they think are value class types (to differentiate them from object class types). Q-descriptors provide this information but have drawbacks like the signature matching issue. Remi?s proposal is appealing because it avoids the signature matching issue. An attribute is not the most convenient data structure for the JVM, but we can record the information elsewhere in our meta-data. However, it seems more brittle because the attribute can easily omitted, unless we make it mandatory after a given class file format number, with a slightly different syntax where all classes named in the class files have to be listed, so it can be verified. For older class file format, the attribute would be absent and all classes are assumed to be object classes. We had two brainstorming sessions. yesterday and this morning, trying to figure out what would be the consequences of having only L-descriptors, with class files having different assumptions regarding the real nature of a type (object class or value class), either in the case of VBC migration or simply because of separate compilation. Some issues are related to the calling/returning conventions for the JIT compiled code. Some others issues are related to the class loader constraints, and the fact that a class with the wrong assumption regarding the nature of a class might prevent the real class from being loaded. The case where a class expects a Value Based Class (object class type) and the class is in fact a migrated value class seems to be OK. The case where a class expects a value class, but the class loader loads an object class seems much more problematic to us. Regarding the migration of value based classes, trying to prevent null references from leaking into migrated code seems to be a step to far. We reviewed the issue with Karen this morning, and it doesn?t seems too dangerous to only check for null when the reference is stored in a field or array expecting an instance of a value class. Thank you, Fred > On Jan 19, 2018, at 23:22, John Rose wrote: > > On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >> >> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >> is the top type of all value classes (as discussed during the November meetings >> in Burlington). > > This is excellent work, Frederic; thank you. I'm really hopeful that we > are on the right track. > >> ... >> Here?s a quick summary of the changes with some consequences on the HotSpot code: >> - all v-bytecodes are removed except vdefault and vwithfield > > At some point we may want to strip the v-prefix from those survivors. No hurry. > >> - all bytecodes operating on an object receiver are updated to support values as well, >> except putfield and new > > Yep. > >> - single carrier type for both instances of object classes and instances of value classes >> - this carrier type maps to the T_OBJECT BasicType >> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) > > T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. > >> - qtos TosState is removed >> - JNI: the jobject type can be used to carry either a reference to an object or an >> array or a value. The type jvaluetype, sub-type of jobject, is used when only >> a value class instance is expected >> - Q?; remains the way to encode value classes in signature (fields and methods) > > I'd like to move towards an ACC_VALUE bit on both fields and classes. > Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. > >> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >> symbolic reference to either an object class or a value class >> - the ;Q escape sequence is not used anymore in value class names >> >> >> One important point of this exercise is to ensure that the migration of Value Based Classes >> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >> on how to deal with the VBC migration. > > I'm glad you are doing this analysis, not only because VBC migration is > a wonderful goal, but also because I think the same analysis is necessary > just to manage separate recompilation, even if we never decided to > migrate a single class. > > In short, I see you are leaning hard on Q-descriptors, but I don't think > you are getting enough value out of them, and they cause serious > problems. More comments below? > >> >> Migration of Value Based Classes into Value Classes: >> - challenges: >> - signature mismatch > > Goes away when/if we retire Q-descriptors! > >> - null > > Can be dealt with by assuming non-null and throwing dynamic NPEs > as needed where Q types are in play. Also, we tolerate "polluting nulls" > along paths where the Q/R distinction is not available, even if (at some > point later on) we realize that it was a Q all along. Eventually, the > polluting null will cause an NPE. > > (In my view, the NPE should happen later than one might prefer if it were > a true coding error rather than a recompilation artifact. Catching polluting > nulls early in the presence of recompilation requires too many heroics.) > >> - change in behavior > > Yes, that's the tricky part. > >> - proposal for signature mismatch: >> - with LWVT, value class types in signatures are using the Q?; format >> - legacy code is using signature with L?; format (because VBC are object classes) >> - methods will have two signatures: >> - true signature, which could include Q?; elements >> - a L-ified signature where all Q?; elements are re-written with the L?; format >> - method lookup still works by signature string comparisons >> - the signature of the method being looked up will compared against both the >> true and the L-ified signatures, if the looked up signature matches the L-ified >> signature but not the true signature, it means a situation where legacy code >> is trying to invoke migrated code has been detected, and additional work might >> be required for the invocation (actions to be taken have to be defined) >> - signature mismatch can also occur for fields, this is still being investigating, the >> proposal will be updated as soon as we have a solution ready to be published > > This sort of thing is, for me, a rich argument against keeping Q-descriptors. > >> - proposal for null references leaking to migrated code >> - having a null reference for a Value Based Class variable or field is valid in legacy code >> but it becomes invalid when the Value Based Class has been migrated to a Value Class >> - trying to prevent all references with a value class type to get a null value would be very >> expensive (it would require to look at the stackmap for each assignment to a local variable) > > Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. > >> - the proposed solution is to allow null references for local variable and expression stack slots, >> but forbid them for fields or array elements (bytecodes operating on fields and array have to >> be updated to throw a NPE whenever a null reference is provided instead of a value class >> instance) > > Yes, I think this is on the right track. On paths where a Q-type is needed > we do a null check. That's the Java way. > >> - null references are likely to be an issue for JIT optimizations like passing values in registers >> when a method is invoked. The proposed solution is to only allow null references for value classes >> in legacy code, by detecting them and blocking them when leaking to migrated code. The >> detection can be done at invocation time, when a mismatch between the signature expected >> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) > > At some point, a polluting null might reach code that "knows" there is a Q type > (and may even "know" that it goes in an xmm register). That's the point where > an NPE should be thrown. In some cases, a deopt might be appropriate, to > correctly order the NPE by executing interpreter code. > > Note that this combination of techniques does not Q-descriptors. The lack > of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you > have to execute a little further before you get to code which "knows" that > the null is illegal. > >> - the null reference should also be detected and blocked when it is used as a return value and the >> type of the value to be returned is a value class type > > Doing this requires (a) Q-descriptors in method returns, (b) Remi's > ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT > doesn't have to tolerate nulls: It can deopt if it hits a surprise null, > or perhaps throw an early NPE.) So, I am arguing for (c). > >> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >> can also help defining which experiments could be done to estimate the costs of the different additional >> checks needed to be added to existing bytecodes. > > The chart is really helpful, thanks. More comments later. > > Onward! > > ? John > > From frederic.parain at oracle.com Wed Jan 24 00:05:50 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 23 Jan 2018 19:05:50 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: Updated JVMS document with a few fixes and the Q-descriptors removed (this removal changed only 3 lines!): http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf No attribute to list value classes has been added yet, so there?s currently some issues for the verification. Fred > On Jan 23, 2018, at 16:25, Frederic Parain wrote: > > Hi John, > > thank you for the detailed feedback. > > The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying > way for class files to express their expectations regarding types they think are value > class types (to differentiate them from object class types). Q-descriptors provide this > information but have drawbacks like the signature matching issue. > > Remi?s proposal is appealing because it avoids the signature matching issue. > An attribute is not the most convenient data structure for the JVM, but we can > record the information elsewhere in our meta-data. However, it seems more > brittle because the attribute can easily omitted, unless we make it mandatory > after a given class file format number, with a slightly different syntax where all > classes named in the class files have to be listed, so it can be verified. For > older class file format, the attribute would be absent and all classes are assumed > to be object classes. > > We had two brainstorming sessions. yesterday and this morning, trying to figure > out what would be the consequences of having only L-descriptors, with class > files having different assumptions regarding the real nature of a type (object class > or value class), either in the case of VBC migration or simply because of separate > compilation. Some issues are related to the calling/returning conventions for the > JIT compiled code. Some others issues are related to the class loader constraints, > and the fact that a class with the wrong assumption regarding the nature of a class > might prevent the real class from being loaded. The case where a class expects > a Value Based Class (object class type) and the class is in fact a migrated value > class seems to be OK. The case where a class expects a value class, but the > class loader loads an object class seems much more problematic to us. > > Regarding the migration of value based classes, trying to prevent null references > from leaking into migrated code seems to be a step to far. We reviewed the issue with > Karen this morning, and it doesn?t seems too dangerous to only check for null > when the reference is stored in a field or array expecting an instance of a value > class. > > Thank you, > > Fred > > >> On Jan 19, 2018, at 23:22, John Rose wrote: >> >> On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >>> >>> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >>> is the top type of all value classes (as discussed during the November meetings >>> in Burlington). >> >> This is excellent work, Frederic; thank you. I'm really hopeful that we >> are on the right track. >> >>> ... >>> Here?s a quick summary of the changes with some consequences on the HotSpot code: >>> - all v-bytecodes are removed except vdefault and vwithfield >> >> At some point we may want to strip the v-prefix from those survivors. No hurry. >> >>> - all bytecodes operating on an object receiver are updated to support values as well, >>> except putfield and new >> >> Yep. >> >>> - single carrier type for both instances of object classes and instances of value classes >>> - this carrier type maps to the T_OBJECT BasicType >>> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) >> >> T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. >> >>> - qtos TosState is removed >>> - JNI: the jobject type can be used to carry either a reference to an object or an >>> array or a value. The type jvaluetype, sub-type of jobject, is used when only >>> a value class instance is expected >>> - Q?; remains the way to encode value classes in signature (fields and methods) >> >> I'd like to move towards an ACC_VALUE bit on both fields and classes. >> Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. >> >>> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >>> symbolic reference to either an object class or a value class >>> - the ;Q escape sequence is not used anymore in value class names >>> >>> >>> One important point of this exercise is to ensure that the migration of Value Based Classes >>> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >>> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >>> on how to deal with the VBC migration. >> >> I'm glad you are doing this analysis, not only because VBC migration is >> a wonderful goal, but also because I think the same analysis is necessary >> just to manage separate recompilation, even if we never decided to >> migrate a single class. >> >> In short, I see you are leaning hard on Q-descriptors, but I don't think >> you are getting enough value out of them, and they cause serious >> problems. More comments below? >> >>> >>> Migration of Value Based Classes into Value Classes: >>> - challenges: >>> - signature mismatch >> >> Goes away when/if we retire Q-descriptors! >> >>> - null >> >> Can be dealt with by assuming non-null and throwing dynamic NPEs >> as needed where Q types are in play. Also, we tolerate "polluting nulls" >> along paths where the Q/R distinction is not available, even if (at some >> point later on) we realize that it was a Q all along. Eventually, the >> polluting null will cause an NPE. >> >> (In my view, the NPE should happen later than one might prefer if it were >> a true coding error rather than a recompilation artifact. Catching polluting >> nulls early in the presence of recompilation requires too many heroics.) >> >>> - change in behavior >> >> Yes, that's the tricky part. >> >>> - proposal for signature mismatch: >>> - with LWVT, value class types in signatures are using the Q?; format >>> - legacy code is using signature with L?; format (because VBC are object classes) >>> - methods will have two signatures: >>> - true signature, which could include Q?; elements >>> - a L-ified signature where all Q?; elements are re-written with the L?; format >>> - method lookup still works by signature string comparisons >>> - the signature of the method being looked up will compared against both the >>> true and the L-ified signatures, if the looked up signature matches the L-ified >>> signature but not the true signature, it means a situation where legacy code >>> is trying to invoke migrated code has been detected, and additional work might >>> be required for the invocation (actions to be taken have to be defined) >>> - signature mismatch can also occur for fields, this is still being investigating, the >>> proposal will be updated as soon as we have a solution ready to be published >> >> This sort of thing is, for me, a rich argument against keeping Q-descriptors. >> >>> - proposal for null references leaking to migrated code >>> - having a null reference for a Value Based Class variable or field is valid in legacy code >>> but it becomes invalid when the Value Based Class has been migrated to a Value Class >>> - trying to prevent all references with a value class type to get a null value would be very >>> expensive (it would require to look at the stackmap for each assignment to a local variable) >> >> Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. >> >>> - the proposed solution is to allow null references for local variable and expression stack slots, >>> but forbid them for fields or array elements (bytecodes operating on fields and array have to >>> be updated to throw a NPE whenever a null reference is provided instead of a value class >>> instance) >> >> Yes, I think this is on the right track. On paths where a Q-type is needed >> we do a null check. That's the Java way. >> >>> - null references are likely to be an issue for JIT optimizations like passing values in registers >>> when a method is invoked. The proposed solution is to only allow null references for value classes >>> in legacy code, by detecting them and blocking them when leaking to migrated code. The >>> detection can be done at invocation time, when a mismatch between the signature expected >>> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) >> >> At some point, a polluting null might reach code that "knows" there is a Q type >> (and may even "know" that it goes in an xmm register). That's the point where >> an NPE should be thrown. In some cases, a deopt might be appropriate, to >> correctly order the NPE by executing interpreter code. >> >> Note that this combination of techniques does not Q-descriptors. The lack >> of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you >> have to execute a little further before you get to code which "knows" that >> the null is illegal. >> >>> - the null reference should also be detected and blocked when it is used as a return value and the >>> type of the value to be returned is a value class type >> >> Doing this requires (a) Q-descriptors in method returns, (b) Remi's >> ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT >> doesn't have to tolerate nulls: It can deopt if it hits a surprise null, >> or perhaps throw an early NPE.) So, I am arguing for (c). >> >>> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >>> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >>> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >>> can also help defining which experiments could be done to estimate the costs of the different additional >>> checks needed to be added to existing bytecodes. >> >> The chart is really helpful, thanks. More comments later. >> >> Onward! >> >> ? John >> >> > From john.r.rose at oracle.com Wed Jan 24 00:22:31 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 23 Jan 2018 16:22:31 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: <3947C280-9CCF-4163-86B6-51329FC373D8@oracle.com> On Jan 23, 2018, at 1:25 PM, Frederic Parain wrote: > > Hi John, > > thank you for the detailed feedback. You are welcome; I'm really glad how well this work is going. > The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying > way for class files to express their expectations regarding types they think are value > class types (to differentiate them from object class types). Q-descriptors provide this > information but have drawbacks like the signature matching issue. Good; I agree. The most important place we were using Q-descriptors was field declarations. Have you tried checking an ACC_VALUE_TYPE bit in value-typed fields? The semantics could be as follows: A. if the bit is set, load the field descriptor class A.1 if the field descriptor class is a value class, DTRT A.2 if the field descriptor class is something else, ignore the ACC_VALUE_TYPE bit (no error) B. if the bit is clear, do not load the field descriptor class; allocate a reference and initialize with null B.1 when storing the reference, test for a buffered value, and store a heap buffer as needed The net of the above semantics is (1) if everybody agrees on the ACC_VALUE_TYPE bits, then we get the semantics we want. But also (2) the ACC_VALUE_TYPE bit becomes (in other cases) an indication to "flatten if possible", and its absence means "don't flatten". That would seem to be not only a good binary compatibility story, but also a useful knob for language implementors. Of course, the JVM also has vote: It could choose to flatten or not, internally, and nobody would know. > Remi?s proposal is appealing because it avoids the signature matching issue. > An attribute is not the most convenient data structure for the JVM, but we can > record the information elsewhere in our meta-data. However, it seems more > brittle because the attribute can easily omitted, unless we make it mandatory > after a given class file format number, with a slightly different syntax where all > classes named in the class files have to be listed, so it can be verified. For > older class file format, the attribute would be absent and all classes are assumed > to be object classes. If we use the semantics suggested above for fields, do we have any need for Remi's attribute? If not, let's start with the field modifier bit. > We had two brainstorming sessions. yesterday and this morning, trying to figure > out what would be the consequences of having only L-descriptors, with class > files having different assumptions regarding the real nature of a type (object class > or value class), either in the case of VBC migration or simply because of separate > compilation. Yes, these issues have to be resolved, and I think we have some good options on the table. > Some issues are related to the calling/returning conventions for the > JIT compiled code. I don't think the JIT's calling sequences need to affect the classfile design. The JIT usually operates with full global information about types, and on the other hand, if global information is sometimes missing, the JIT routinely backs off to a safe assumption. In this case, an unknown type can be passed (suboptimally) as L-Object in L-world. > Some others issues are related to the class loader constraints, > and the fact that a class with the wrong assumption regarding the nature of a class > might prevent the real class from being loaded. IMO, the best way to deal with CLCs is not make new kinds of them. > The case where a class expects > a Value Based Class (object class type) and the class is in fact a migrated value > class seems to be OK. Awesome! > The case where a class expects a value class, but the > class loader loads an object class seems much more problematic to us. Please list the problems? Some of them can be dealt with as noted above by backing off to L-Object (which is a heap pointer). > Regarding the migration of value based classes, trying to prevent null references > from leaking into migrated code seems to be a step to far. I am so glad to hear this. I fully agree. > We reviewed the issue with > Karen this morning, and it doesn?t seems too dangerous to only check for null > when the reference is stored in a field or array expecting an instance of a value > class. Excellent; let's prototype that and see how it feels. ? John > > Thank you, > > Fred > > >> On Jan 19, 2018, at 23:22, John Rose wrote: >> >> On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >>> >>> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >>> is the top type of all value classes (as discussed during the November meetings >>> in Burlington). >> >> This is excellent work, Frederic; thank you. I'm really hopeful that we >> are on the right track. >> >>> ... >>> Here?s a quick summary of the changes with some consequences on the HotSpot code: >>> - all v-bytecodes are removed except vdefault and vwithfield >> >> At some point we may want to strip the v-prefix from those survivors. No hurry. >> >>> - all bytecodes operating on an object receiver are updated to support values as well, >>> except putfield and new >> >> Yep. >> >>> - single carrier type for both instances of object classes and instances of value classes >>> - this carrier type maps to the T_OBJECT BasicType >>> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) >> >> T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. >> >>> - qtos TosState is removed >>> - JNI: the jobject type can be used to carry either a reference to an object or an >>> array or a value. The type jvaluetype, sub-type of jobject, is used when only >>> a value class instance is expected >>> - Q?; remains the way to encode value classes in signature (fields and methods) >> >> I'd like to move towards an ACC_VALUE bit on both fields and classes. >> Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. >> >>> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >>> symbolic reference to either an object class or a value class >>> - the ;Q escape sequence is not used anymore in value class names >>> >>> >>> One important point of this exercise is to ensure that the migration of Value Based Classes >>> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >>> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >>> on how to deal with the VBC migration. >> >> I'm glad you are doing this analysis, not only because VBC migration is >> a wonderful goal, but also because I think the same analysis is necessary >> just to manage separate recompilation, even if we never decided to >> migrate a single class. >> >> In short, I see you are leaning hard on Q-descriptors, but I don't think >> you are getting enough value out of them, and they cause serious >> problems. More comments below? >> >>> >>> Migration of Value Based Classes into Value Classes: >>> - challenges: >>> - signature mismatch >> >> Goes away when/if we retire Q-descriptors! >> >>> - null >> >> Can be dealt with by assuming non-null and throwing dynamic NPEs >> as needed where Q types are in play. Also, we tolerate "polluting nulls" >> along paths where the Q/R distinction is not available, even if (at some >> point later on) we realize that it was a Q all along. Eventually, the >> polluting null will cause an NPE. >> >> (In my view, the NPE should happen later than one might prefer if it were >> a true coding error rather than a recompilation artifact. Catching polluting >> nulls early in the presence of recompilation requires too many heroics.) >> >>> - change in behavior >> >> Yes, that's the tricky part. >> >>> - proposal for signature mismatch: >>> - with LWVT, value class types in signatures are using the Q?; format >>> - legacy code is using signature with L?; format (because VBC are object classes) >>> - methods will have two signatures: >>> - true signature, which could include Q?; elements >>> - a L-ified signature where all Q?; elements are re-written with the L?; format >>> - method lookup still works by signature string comparisons >>> - the signature of the method being looked up will compared against both the >>> true and the L-ified signatures, if the looked up signature matches the L-ified >>> signature but not the true signature, it means a situation where legacy code >>> is trying to invoke migrated code has been detected, and additional work might >>> be required for the invocation (actions to be taken have to be defined) >>> - signature mismatch can also occur for fields, this is still being investigating, the >>> proposal will be updated as soon as we have a solution ready to be published >> >> This sort of thing is, for me, a rich argument against keeping Q-descriptors. >> >>> - proposal for null references leaking to migrated code >>> - having a null reference for a Value Based Class variable or field is valid in legacy code >>> but it becomes invalid when the Value Based Class has been migrated to a Value Class >>> - trying to prevent all references with a value class type to get a null value would be very >>> expensive (it would require to look at the stackmap for each assignment to a local variable) >> >> Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. >> >>> - the proposed solution is to allow null references for local variable and expression stack slots, >>> but forbid them for fields or array elements (bytecodes operating on fields and array have to >>> be updated to throw a NPE whenever a null reference is provided instead of a value class >>> instance) >> >> Yes, I think this is on the right track. On paths where a Q-type is needed >> we do a null check. That's the Java way. >> >>> - null references are likely to be an issue for JIT optimizations like passing values in registers >>> when a method is invoked. The proposed solution is to only allow null references for value classes >>> in legacy code, by detecting them and blocking them when leaking to migrated code. The >>> detection can be done at invocation time, when a mismatch between the signature expected >>> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) >> >> At some point, a polluting null might reach code that "knows" there is a Q type >> (and may even "know" that it goes in an xmm register). That's the point where >> an NPE should be thrown. In some cases, a deopt might be appropriate, to >> correctly order the NPE by executing interpreter code. >> >> Note that this combination of techniques does not Q-descriptors. The lack >> of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you >> have to execute a little further before you get to code which "knows" that >> the null is illegal. >> >>> - the null reference should also be detected and blocked when it is used as a return value and the >>> type of the value to be returned is a value class type >> >> Doing this requires (a) Q-descriptors in method returns, (b) Remi's >> ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT >> doesn't have to tolerate nulls: It can deopt if it hits a surprise null, >> or perhaps throw an early NPE.) So, I am arguing for (c). >> >>> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >>> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >>> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >>> can also help defining which experiments could be done to estimate the costs of the different additional >>> checks needed to be added to existing bytecodes. >> >> The chart is really helpful, thanks. More comments later. >> >> Onward! >> >> ? John >> >> > From david.holmes at oracle.com Wed Jan 24 09:36:22 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 24 Jan 2018 09:36:22 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <201801240936.w0O9aNHi010082@aojmv0008.oracle.com> Changeset: 9d79e658efe6 Author: dholmes Date: 2018-01-24 04:31 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/9d79e658efe6 Merge ! make/autoconf/generated-configure.sh ! make/mapfiles/libjava/mapfile-vers ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/sparc/templateTable_sparc.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/native/libjava/Reflection.c - src/java.compiler/share/classes/javax/lang/model/overview.html - src/java.compiler/share/classes/javax/tools/FileManagerUtils.java - src/java.compiler/share/classes/javax/tools/overview.html - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java - src/jdk.jdeps/share/classes/com/sun/tools/javap/overview.html - src/jdk.unsupported/share/classes/sun/reflect/Reflection.java ! test/jdk/ProblemList.txt - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassWithDepth.java - test/jdk/sun/reflect/Reflection/GetCallerClassWithDepth.java - test/langtools/tools/javac/T8192885/AddGotoAfterForLoopToLNTTest.java From david.holmes at oracle.com Wed Jan 24 10:16:43 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 24 Jan 2018 10:16:43 +0000 Subject: hg: valhalla/valhalla: Fix mis-generated file Message-ID: <201801241016.w0OAGhe0024179@aojmv0008.oracle.com> Changeset: 471e0b00fc60 Author: dholmes Date: 2018-01-24 05:12 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/471e0b00fc60 Fix mis-generated file ! make/autoconf/generated-configure.sh From frederic.parain at oracle.com Wed Jan 24 14:34:30 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 24 Jan 2018 09:34:30 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> Message-ID: <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> I?ve uploaded a quick summary of the potential issues that can be caused by a mismatch between the expected and the real nature of a class (object class or value class). http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-1.pdf If some cases are missing or incorrect, please let me know. Fred > On Jan 23, 2018, at 19:05, Frederic Parain wrote: > > Updated JVMS document with a few fixes and the Q-descriptors > removed (this removal changed only 3 lines!): > > http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf > > No attribute to list value classes has been added yet, so there?s > currently some issues for the verification. > > Fred > >> On Jan 23, 2018, at 16:25, Frederic Parain wrote: >> >> Hi John, >> >> thank you for the detailed feedback. >> >> The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying >> way for class files to express their expectations regarding types they think are value >> class types (to differentiate them from object class types). Q-descriptors provide this >> information but have drawbacks like the signature matching issue. >> >> Remi?s proposal is appealing because it avoids the signature matching issue. >> An attribute is not the most convenient data structure for the JVM, but we can >> record the information elsewhere in our meta-data. However, it seems more >> brittle because the attribute can easily omitted, unless we make it mandatory >> after a given class file format number, with a slightly different syntax where all >> classes named in the class files have to be listed, so it can be verified. For >> older class file format, the attribute would be absent and all classes are assumed >> to be object classes. >> >> We had two brainstorming sessions. yesterday and this morning, trying to figure >> out what would be the consequences of having only L-descriptors, with class >> files having different assumptions regarding the real nature of a type (object class >> or value class), either in the case of VBC migration or simply because of separate >> compilation. Some issues are related to the calling/returning conventions for the >> JIT compiled code. Some others issues are related to the class loader constraints, >> and the fact that a class with the wrong assumption regarding the nature of a class >> might prevent the real class from being loaded. The case where a class expects >> a Value Based Class (object class type) and the class is in fact a migrated value >> class seems to be OK. The case where a class expects a value class, but the >> class loader loads an object class seems much more problematic to us. >> >> Regarding the migration of value based classes, trying to prevent null references >> from leaking into migrated code seems to be a step to far. We reviewed the issue with >> Karen this morning, and it doesn?t seems too dangerous to only check for null >> when the reference is stored in a field or array expecting an instance of a value >> class. >> >> Thank you, >> >> Fred >> >> >>> On Jan 19, 2018, at 23:22, John Rose wrote: >>> >>> On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >>>> >>>> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >>>> is the top type of all value classes (as discussed during the November meetings >>>> in Burlington). >>> >>> This is excellent work, Frederic; thank you. I'm really hopeful that we >>> are on the right track. >>> >>>> ... >>>> Here?s a quick summary of the changes with some consequences on the HotSpot code: >>>> - all v-bytecodes are removed except vdefault and vwithfield >>> >>> At some point we may want to strip the v-prefix from those survivors. No hurry. >>> >>>> - all bytecodes operating on an object receiver are updated to support values as well, >>>> except putfield and new >>> >>> Yep. >>> >>>> - single carrier type for both instances of object classes and instances of value classes >>>> - this carrier type maps to the T_OBJECT BasicType >>>> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) >>> >>> T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. >>> >>>> - qtos TosState is removed >>>> - JNI: the jobject type can be used to carry either a reference to an object or an >>>> array or a value. The type jvaluetype, sub-type of jobject, is used when only >>>> a value class instance is expected >>>> - Q?; remains the way to encode value classes in signature (fields and methods) >>> >>> I'd like to move towards an ACC_VALUE bit on both fields and classes. >>> Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. >>> >>>> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >>>> symbolic reference to either an object class or a value class >>>> - the ;Q escape sequence is not used anymore in value class names >>>> >>>> >>>> One important point of this exercise is to ensure that the migration of Value Based Classes >>>> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >>>> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >>>> on how to deal with the VBC migration. >>> >>> I'm glad you are doing this analysis, not only because VBC migration is >>> a wonderful goal, but also because I think the same analysis is necessary >>> just to manage separate recompilation, even if we never decided to >>> migrate a single class. >>> >>> In short, I see you are leaning hard on Q-descriptors, but I don't think >>> you are getting enough value out of them, and they cause serious >>> problems. More comments below? >>> >>>> >>>> Migration of Value Based Classes into Value Classes: >>>> - challenges: >>>> - signature mismatch >>> >>> Goes away when/if we retire Q-descriptors! >>> >>>> - null >>> >>> Can be dealt with by assuming non-null and throwing dynamic NPEs >>> as needed where Q types are in play. Also, we tolerate "polluting nulls" >>> along paths where the Q/R distinction is not available, even if (at some >>> point later on) we realize that it was a Q all along. Eventually, the >>> polluting null will cause an NPE. >>> >>> (In my view, the NPE should happen later than one might prefer if it were >>> a true coding error rather than a recompilation artifact. Catching polluting >>> nulls early in the presence of recompilation requires too many heroics.) >>> >>>> - change in behavior >>> >>> Yes, that's the tricky part. >>> >>>> - proposal for signature mismatch: >>>> - with LWVT, value class types in signatures are using the Q?; format >>>> - legacy code is using signature with L?; format (because VBC are object classes) >>>> - methods will have two signatures: >>>> - true signature, which could include Q?; elements >>>> - a L-ified signature where all Q?; elements are re-written with the L?; format >>>> - method lookup still works by signature string comparisons >>>> - the signature of the method being looked up will compared against both the >>>> true and the L-ified signatures, if the looked up signature matches the L-ified >>>> signature but not the true signature, it means a situation where legacy code >>>> is trying to invoke migrated code has been detected, and additional work might >>>> be required for the invocation (actions to be taken have to be defined) >>>> - signature mismatch can also occur for fields, this is still being investigating, the >>>> proposal will be updated as soon as we have a solution ready to be published >>> >>> This sort of thing is, for me, a rich argument against keeping Q-descriptors. >>> >>>> - proposal for null references leaking to migrated code >>>> - having a null reference for a Value Based Class variable or field is valid in legacy code >>>> but it becomes invalid when the Value Based Class has been migrated to a Value Class >>>> - trying to prevent all references with a value class type to get a null value would be very >>>> expensive (it would require to look at the stackmap for each assignment to a local variable) >>> >>> Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. >>> >>>> - the proposed solution is to allow null references for local variable and expression stack slots, >>>> but forbid them for fields or array elements (bytecodes operating on fields and array have to >>>> be updated to throw a NPE whenever a null reference is provided instead of a value class >>>> instance) >>> >>> Yes, I think this is on the right track. On paths where a Q-type is needed >>> we do a null check. That's the Java way. >>> >>>> - null references are likely to be an issue for JIT optimizations like passing values in registers >>>> when a method is invoked. The proposed solution is to only allow null references for value classes >>>> in legacy code, by detecting them and blocking them when leaking to migrated code. The >>>> detection can be done at invocation time, when a mismatch between the signature expected >>>> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) >>> >>> At some point, a polluting null might reach code that "knows" there is a Q type >>> (and may even "know" that it goes in an xmm register). That's the point where >>> an NPE should be thrown. In some cases, a deopt might be appropriate, to >>> correctly order the NPE by executing interpreter code. >>> >>> Note that this combination of techniques does not Q-descriptors. The lack >>> of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you >>> have to execute a little further before you get to code which "knows" that >>> the null is illegal. >>> >>>> - the null reference should also be detected and blocked when it is used as a return value and the >>>> type of the value to be returned is a value class type >>> >>> Doing this requires (a) Q-descriptors in method returns, (b) Remi's >>> ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT >>> doesn't have to tolerate nulls: It can deopt if it hits a surprise null, >>> or perhaps throw an early NPE.) So, I am arguing for (c). >>> >>>> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >>>> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >>>> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >>>> can also help defining which experiments could be done to estimate the costs of the different additional >>>> checks needed to be added to existing bytecodes. >>> >>> The chart is really helpful, thanks. More comments later. >>> >>> Onward! >>> >>> ? John >>> >>> >> > From bdelsart.work at gmail.com Wed Jan 24 15:51:27 2018 From: bdelsart.work at gmail.com (bdelsart work) Date: Wed, 24 Jan 2018 16:51:27 +0100 Subject: RFR: 8193472 [Valhalla] Interpreter should be able to return values in TLVB In-Reply-To: <219F4F0E-B91D-4FE6-AA17-5A9280BEB42F@oracle.com> References: <219F4F0E-B91D-4FE6-AA17-5A9280BEB42F@oracle.com> Message-ID: Salut Fred et bonne ann?e. Je n'ai pas vu de r?ponse ? ce RFR. Pr?viens moi si il toujours d'actualit? et si tu as besoin que je m'en occupe. Amicalement, Bertrand. -- Freelance - Bertrand Delsart Software Solutions Remote Research, Development and Troubleshooting JVM, Real-Time and Concurrency expert http://www.bdelsart.com 2017-12-13 21:42 GMT+01:00 Frederic Parain : > Please, review this fix to improve the way values are returned by the > interpreter, > using the Thread-Local Value Buffer whenever possible. The return in the > TLVB > is currently disabled, because some fixes are required in JIT code. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8193472 > > Webrev: > http://cr.openjdk.java.net/~fparain/8193472/webrev.00/index.html > > Thank you, > > Fred From frederic.parain at oracle.com Wed Jan 24 16:42:25 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 24 Jan 2018 11:42:25 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> Message-ID: <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> Updated chart after Valhalla?s VM Meeting: http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-2.pdf Fred > On Jan 24, 2018, at 09:34, Frederic Parain wrote: > > I?ve uploaded a quick summary of the potential issues that can be caused > by a mismatch between the expected and the real nature of a class (object > class or value class). > > http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-1.pdf > > If some cases are missing or incorrect, please let me know. > > Fred > > >> On Jan 23, 2018, at 19:05, Frederic Parain wrote: >> >> Updated JVMS document with a few fixes and the Q-descriptors >> removed (this removal changed only 3 lines!): >> >> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf >> >> No attribute to list value classes has been added yet, so there?s >> currently some issues for the verification. >> >> Fred >> >>> On Jan 23, 2018, at 16:25, Frederic Parain wrote: >>> >>> Hi John, >>> >>> thank you for the detailed feedback. >>> >>> The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying >>> way for class files to express their expectations regarding types they think are value >>> class types (to differentiate them from object class types). Q-descriptors provide this >>> information but have drawbacks like the signature matching issue. >>> >>> Remi?s proposal is appealing because it avoids the signature matching issue. >>> An attribute is not the most convenient data structure for the JVM, but we can >>> record the information elsewhere in our meta-data. However, it seems more >>> brittle because the attribute can easily omitted, unless we make it mandatory >>> after a given class file format number, with a slightly different syntax where all >>> classes named in the class files have to be listed, so it can be verified. For >>> older class file format, the attribute would be absent and all classes are assumed >>> to be object classes. >>> >>> We had two brainstorming sessions. yesterday and this morning, trying to figure >>> out what would be the consequences of having only L-descriptors, with class >>> files having different assumptions regarding the real nature of a type (object class >>> or value class), either in the case of VBC migration or simply because of separate >>> compilation. Some issues are related to the calling/returning conventions for the >>> JIT compiled code. Some others issues are related to the class loader constraints, >>> and the fact that a class with the wrong assumption regarding the nature of a class >>> might prevent the real class from being loaded. The case where a class expects >>> a Value Based Class (object class type) and the class is in fact a migrated value >>> class seems to be OK. The case where a class expects a value class, but the >>> class loader loads an object class seems much more problematic to us. >>> >>> Regarding the migration of value based classes, trying to prevent null references >>> from leaking into migrated code seems to be a step to far. We reviewed the issue with >>> Karen this morning, and it doesn?t seems too dangerous to only check for null >>> when the reference is stored in a field or array expecting an instance of a value >>> class. >>> >>> Thank you, >>> >>> Fred >>> >>> >>>> On Jan 19, 2018, at 23:22, John Rose wrote: >>>> >>>> On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >>>>> >>>>> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >>>>> is the top type of all value classes (as discussed during the November meetings >>>>> in Burlington). >>>> >>>> This is excellent work, Frederic; thank you. I'm really hopeful that we >>>> are on the right track. >>>> >>>>> ... >>>>> Here?s a quick summary of the changes with some consequences on the HotSpot code: >>>>> - all v-bytecodes are removed except vdefault and vwithfield >>>> >>>> At some point we may want to strip the v-prefix from those survivors. No hurry. >>>> >>>>> - all bytecodes operating on an object receiver are updated to support values as well, >>>>> except putfield and new >>>> >>>> Yep. >>>> >>>>> - single carrier type for both instances of object classes and instances of value classes >>>>> - this carrier type maps to the T_OBJECT BasicType >>>>> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) >>>> >>>> T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. >>>> >>>>> - qtos TosState is removed >>>>> - JNI: the jobject type can be used to carry either a reference to an object or an >>>>> array or a value. The type jvaluetype, sub-type of jobject, is used when only >>>>> a value class instance is expected >>>>> - Q?; remains the way to encode value classes in signature (fields and methods) >>>> >>>> I'd like to move towards an ACC_VALUE bit on both fields and classes. >>>> Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. >>>> >>>>> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >>>>> symbolic reference to either an object class or a value class >>>>> - the ;Q escape sequence is not used anymore in value class names >>>>> >>>>> >>>>> One important point of this exercise is to ensure that the migration of Value Based Classes >>>>> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >>>>> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >>>>> on how to deal with the VBC migration. >>>> >>>> I'm glad you are doing this analysis, not only because VBC migration is >>>> a wonderful goal, but also because I think the same analysis is necessary >>>> just to manage separate recompilation, even if we never decided to >>>> migrate a single class. >>>> >>>> In short, I see you are leaning hard on Q-descriptors, but I don't think >>>> you are getting enough value out of them, and they cause serious >>>> problems. More comments below? >>>> >>>>> >>>>> Migration of Value Based Classes into Value Classes: >>>>> - challenges: >>>>> - signature mismatch >>>> >>>> Goes away when/if we retire Q-descriptors! >>>> >>>>> - null >>>> >>>> Can be dealt with by assuming non-null and throwing dynamic NPEs >>>> as needed where Q types are in play. Also, we tolerate "polluting nulls" >>>> along paths where the Q/R distinction is not available, even if (at some >>>> point later on) we realize that it was a Q all along. Eventually, the >>>> polluting null will cause an NPE. >>>> >>>> (In my view, the NPE should happen later than one might prefer if it were >>>> a true coding error rather than a recompilation artifact. Catching polluting >>>> nulls early in the presence of recompilation requires too many heroics.) >>>> >>>>> - change in behavior >>>> >>>> Yes, that's the tricky part. >>>> >>>>> - proposal for signature mismatch: >>>>> - with LWVT, value class types in signatures are using the Q?; format >>>>> - legacy code is using signature with L?; format (because VBC are object classes) >>>>> - methods will have two signatures: >>>>> - true signature, which could include Q?; elements >>>>> - a L-ified signature where all Q?; elements are re-written with the L?; format >>>>> - method lookup still works by signature string comparisons >>>>> - the signature of the method being looked up will compared against both the >>>>> true and the L-ified signatures, if the looked up signature matches the L-ified >>>>> signature but not the true signature, it means a situation where legacy code >>>>> is trying to invoke migrated code has been detected, and additional work might >>>>> be required for the invocation (actions to be taken have to be defined) >>>>> - signature mismatch can also occur for fields, this is still being investigating, the >>>>> proposal will be updated as soon as we have a solution ready to be published >>>> >>>> This sort of thing is, for me, a rich argument against keeping Q-descriptors. >>>> >>>>> - proposal for null references leaking to migrated code >>>>> - having a null reference for a Value Based Class variable or field is valid in legacy code >>>>> but it becomes invalid when the Value Based Class has been migrated to a Value Class >>>>> - trying to prevent all references with a value class type to get a null value would be very >>>>> expensive (it would require to look at the stackmap for each assignment to a local variable) >>>> >>>> Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. >>>> >>>>> - the proposed solution is to allow null references for local variable and expression stack slots, >>>>> but forbid them for fields or array elements (bytecodes operating on fields and array have to >>>>> be updated to throw a NPE whenever a null reference is provided instead of a value class >>>>> instance) >>>> >>>> Yes, I think this is on the right track. On paths where a Q-type is needed >>>> we do a null check. That's the Java way. >>>> >>>>> - null references are likely to be an issue for JIT optimizations like passing values in registers >>>>> when a method is invoked. The proposed solution is to only allow null references for value classes >>>>> in legacy code, by detecting them and blocking them when leaking to migrated code. The >>>>> detection can be done at invocation time, when a mismatch between the signature expected >>>>> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) >>>> >>>> At some point, a polluting null might reach code that "knows" there is a Q type >>>> (and may even "know" that it goes in an xmm register). That's the point where >>>> an NPE should be thrown. In some cases, a deopt might be appropriate, to >>>> correctly order the NPE by executing interpreter code. >>>> >>>> Note that this combination of techniques does not Q-descriptors. The lack >>>> of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you >>>> have to execute a little further before you get to code which "knows" that >>>> the null is illegal. >>>> >>>>> - the null reference should also be detected and blocked when it is used as a return value and the >>>>> type of the value to be returned is a value class type >>>> >>>> Doing this requires (a) Q-descriptors in method returns, (b) Remi's >>>> ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT >>>> doesn't have to tolerate nulls: It can deopt if it hits a surprise null, >>>> or perhaps throw an early NPE.) So, I am arguing for (c). >>>> >>>>> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >>>>> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >>>>> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >>>>> can also help defining which experiments could be done to estimate the costs of the different additional >>>>> checks needed to be added to existing bytecodes. >>>> >>>> The chart is really helpful, thanks. More comments later. >>>> >>>> Onward! >>>> >>>> ? John >>>> >>>> >>> >> > From forax at univ-mlv.fr Wed Jan 24 18:45:38 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 24 Jan 2018 18:45:38 +0000 Subject: [Exp] Experimenting with "value-based" classes and oop testing In-Reply-To: <747A09D3-511F-4DEE-9E58-C99F748E115D@oracle.com> References: <1505025090.1788134.1516291751034.JavaMail.zimbra@u-pem.fr> <79d07633-7f59-db6c-b95c-22703c1b6d08@oracle.com> <747A09D3-511F-4DEE-9E58-C99F748E115D@oracle.com> Message-ID: <30709B87-8886-4E5C-B85C-430F022204E1@univ-mlv.fr> On January 19, 2018 10:00:36 PM UTC, John Rose wrote: >+100 to this experiment; as a whole it's the right thing to try. > >It might give us the fast acmp hack we need for L-world. > >A couple of comments: > >> On Jan 19, 2018, at 12:25 AM, David Simms >wrote: >>> >>> >>> my other question is what is the purpose to have a value based class >with mutable fields ? >>> >>> R?mi >> >> Hehe, yeah ValueBased test itself doesn't follow the rules, will >adjust. >> >> Also thinking of adding some form of auto-value classification to >class file parser, identify value type candidates in existing >benchmarks, so we can see L-World costs > >Another way to slice it would be to have a classfile scanner which >spits out the names of value-able candidate classes. That could >be eyeballed and then plugged into -XX:ValueBasedClasses=? > >I'll bet it could be hacked up in an afternoon in ASM. Remi? https://gist.github.com/forax/38935d18aaedc08a32610a7cbc68885e I use an internal version of ASM 7, but it should work with the internal version of the ask by replacing ASM7 by ASM6 in the source code. I just check if the class is final, the super class is Object and all fields are final, is it enough ? > >About mutable immutables, there is actually something worth >saying: We sometimes think about designing a _larval typestate_ >for immutables (of both object and value types) which would >be mutable. It would be a private container for field values. >Once it is loaded, it get promoted to the publishable _adult >typestate_. See [1]. We would need to figure out rules for >keeping the typestates separate, so that larval objects >are not accidentally published (leading to races) and >so that adult objects are not accidentally mutated as if >they were still under construction. > >That last requirement is best solved, I claim, by >introducing a mechanism for single-thread confinement, >enforced by the JVM. > >These ideas are worth mulling over from time to time, >as a better way to organize immutables than the standard >technique of manually written builder objects like >StringBuilder (and various collection builders). > >Anyway, if a value type has a larval object state, its >fields *would* be writable, but in that state *only*. >Of course, as it pupates to the adult state it would >shed its object identity as well as its mutability. > >If it were a true object class it would shed only >its mutability. It might *change* its identity, as >in the case of StringBuilder.toString. Note that >a StringBuilder *does* change identity when >promoting to the "adult" String. > >Maybe we can do something about typestate >with template classes?if a template could expand >to both objects and value species! > >? John Remi > >[1] https://blogs.oracle.com/jrose/larval-objects-in-the-vm -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From karen.kinnear at oracle.com Wed Jan 24 19:32:32 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 24 Jan 2018 14:32:32 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> Message-ID: <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> Frederic, Many thanks for the JVMS rough draft, chart of bytecodes and what checking they need and the mismatch chart. They are extremely helpful. Questions/comments on the JVMS: http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf 2.4 In the paragraph that describes null related to references: The null reference initially has no run-time type, but may be cast to any type (implies checkcast, instanceof will continue unchanged - which is our current proposal) The default value of a reference type is null. - Should that be the default value of an object class type is null? Do we want to describe the default value of a value class type? Perhaps we can leave these changes for Dan. 4.1/ 4.5 From our discussion today, it sounds as though we can try Remi?s original/John?s proposal for just tracking knowledge of a value type in the class file at two places: 1) when declaring a class, the class access_flags would add ACC_VALUE_TYPE 2) when declaring a field, the field access_flags would add ACC_VALUE_TYPE (small note - can we use 0x100?) 4.1 There is a comment that it is invalid to have ACC_INTERFACE and ACC_VALUE_TYPE I believe it should also be invalid to have ACC_ABSTRACT and ACC_VALUE_TYPE 6 invoke special Where do we throw an exception if we have an method in a value class? Would that be verifier? Just in case they skip verification, might it be worth throwing an exception if the resolved method is an instance initialization method and the class is a value class - would that be an ICCE? or a NoSuchMethodError? 6 monitorenter Run-time Exception: ?iff object ref? -> ?if object ref? ?monitor exit throws a IllegalMonitorStateException? -> ?monitorenter? (and ?an? before vowel Illegal?) thanks, Karen > On Jan 24, 2018, at 11:42 AM, Frederic Parain wrote: > > Updated chart after Valhalla?s VM Meeting: > > http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-2.pdf > > Fred > >> On Jan 24, 2018, at 09:34, Frederic Parain wrote: >> >> I?ve uploaded a quick summary of the potential issues that can be caused >> by a mismatch between the expected and the real nature of a class (object >> class or value class). >> >> http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-1.pdf >> >> If some cases are missing or incorrect, please let me know. >> >> Fred >> >> >>> On Jan 23, 2018, at 19:05, Frederic Parain wrote: >>> >>> Updated JVMS document with a few fixes and the Q-descriptors >>> removed (this removal changed only 3 lines!): >>> >>> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf >>> >>> No attribute to list value classes has been added yet, so there?s >>> currently some issues for the verification. >>> >>> Fred >>> >>>> On Jan 23, 2018, at 16:25, Frederic Parain wrote: >>>> >>>> Hi John, >>>> >>>> thank you for the detailed feedback. >>>> >>>> The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying >>>> way for class files to express their expectations regarding types they think are value >>>> class types (to differentiate them from object class types). Q-descriptors provide this >>>> information but have drawbacks like the signature matching issue. >>>> >>>> Remi?s proposal is appealing because it avoids the signature matching issue. >>>> An attribute is not the most convenient data structure for the JVM, but we can >>>> record the information elsewhere in our meta-data. However, it seems more >>>> brittle because the attribute can easily omitted, unless we make it mandatory >>>> after a given class file format number, with a slightly different syntax where all >>>> classes named in the class files have to be listed, so it can be verified. For >>>> older class file format, the attribute would be absent and all classes are assumed >>>> to be object classes. >>>> >>>> We had two brainstorming sessions. yesterday and this morning, trying to figure >>>> out what would be the consequences of having only L-descriptors, with class >>>> files having different assumptions regarding the real nature of a type (object class >>>> or value class), either in the case of VBC migration or simply because of separate >>>> compilation. Some issues are related to the calling/returning conventions for the >>>> JIT compiled code. Some others issues are related to the class loader constraints, >>>> and the fact that a class with the wrong assumption regarding the nature of a class >>>> might prevent the real class from being loaded. The case where a class expects >>>> a Value Based Class (object class type) and the class is in fact a migrated value >>>> class seems to be OK. The case where a class expects a value class, but the >>>> class loader loads an object class seems much more problematic to us. >>>> >>>> Regarding the migration of value based classes, trying to prevent null references >>>> from leaking into migrated code seems to be a step to far. We reviewed the issue with >>>> Karen this morning, and it doesn?t seems too dangerous to only check for null >>>> when the reference is stored in a field or array expecting an instance of a value >>>> class. >>>> >>>> Thank you, >>>> >>>> Fred >>>> >>>> >>>>> On Jan 19, 2018, at 23:22, John Rose wrote: >>>>> >>>>> On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >>>>>> >>>>>> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >>>>>> is the top type of all value classes (as discussed during the November meetings >>>>>> in Burlington). >>>>> >>>>> This is excellent work, Frederic; thank you. I'm really hopeful that we >>>>> are on the right track. >>>>> >>>>>> ... >>>>>> Here?s a quick summary of the changes with some consequences on the HotSpot code: >>>>>> - all v-bytecodes are removed except vdefault and vwithfield >>>>> >>>>> At some point we may want to strip the v-prefix from those survivors. No hurry. >>>>> >>>>>> - all bytecodes operating on an object receiver are updated to support values as well, >>>>>> except putfield and new >>>>> >>>>> Yep. >>>>> >>>>>> - single carrier type for both instances of object classes and instances of value classes >>>>>> - this carrier type maps to the T_OBJECT BasicType >>>>>> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) >>>>> >>>>> T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. >>>>> >>>>>> - qtos TosState is removed >>>>>> - JNI: the jobject type can be used to carry either a reference to an object or an >>>>>> array or a value. The type jvaluetype, sub-type of jobject, is used when only >>>>>> a value class instance is expected >>>>>> - Q?; remains the way to encode value classes in signature (fields and methods) >>>>> >>>>> I'd like to move towards an ACC_VALUE bit on both fields and classes. >>>>> Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. >>>>> >>>>>> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >>>>>> symbolic reference to either an object class or a value class >>>>>> - the ;Q escape sequence is not used anymore in value class names >>>>>> >>>>>> >>>>>> One important point of this exercise is to ensure that the migration of Value Based Classes >>>>>> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >>>>>> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >>>>>> on how to deal with the VBC migration. >>>>> >>>>> I'm glad you are doing this analysis, not only because VBC migration is >>>>> a wonderful goal, but also because I think the same analysis is necessary >>>>> just to manage separate recompilation, even if we never decided to >>>>> migrate a single class. >>>>> >>>>> In short, I see you are leaning hard on Q-descriptors, but I don't think >>>>> you are getting enough value out of them, and they cause serious >>>>> problems. More comments below? >>>>> >>>>>> >>>>>> Migration of Value Based Classes into Value Classes: >>>>>> - challenges: >>>>>> - signature mismatch >>>>> >>>>> Goes away when/if we retire Q-descriptors! >>>>> >>>>>> - null >>>>> >>>>> Can be dealt with by assuming non-null and throwing dynamic NPEs >>>>> as needed where Q types are in play. Also, we tolerate "polluting nulls" >>>>> along paths where the Q/R distinction is not available, even if (at some >>>>> point later on) we realize that it was a Q all along. Eventually, the >>>>> polluting null will cause an NPE. >>>>> >>>>> (In my view, the NPE should happen later than one might prefer if it were >>>>> a true coding error rather than a recompilation artifact. Catching polluting >>>>> nulls early in the presence of recompilation requires too many heroics.) >>>>> >>>>>> - change in behavior >>>>> >>>>> Yes, that's the tricky part. >>>>> >>>>>> - proposal for signature mismatch: >>>>>> - with LWVT, value class types in signatures are using the Q?; format >>>>>> - legacy code is using signature with L?; format (because VBC are object classes) >>>>>> - methods will have two signatures: >>>>>> - true signature, which could include Q?; elements >>>>>> - a L-ified signature where all Q?; elements are re-written with the L?; format >>>>>> - method lookup still works by signature string comparisons >>>>>> - the signature of the method being looked up will compared against both the >>>>>> true and the L-ified signatures, if the looked up signature matches the L-ified >>>>>> signature but not the true signature, it means a situation where legacy code >>>>>> is trying to invoke migrated code has been detected, and additional work might >>>>>> be required for the invocation (actions to be taken have to be defined) >>>>>> - signature mismatch can also occur for fields, this is still being investigating, the >>>>>> proposal will be updated as soon as we have a solution ready to be published >>>>> >>>>> This sort of thing is, for me, a rich argument against keeping Q-descriptors. >>>>> >>>>>> - proposal for null references leaking to migrated code >>>>>> - having a null reference for a Value Based Class variable or field is valid in legacy code >>>>>> but it becomes invalid when the Value Based Class has been migrated to a Value Class >>>>>> - trying to prevent all references with a value class type to get a null value would be very >>>>>> expensive (it would require to look at the stackmap for each assignment to a local variable) >>>>> >>>>> Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. >>>>> >>>>>> - the proposed solution is to allow null references for local variable and expression stack slots, >>>>>> but forbid them for fields or array elements (bytecodes operating on fields and array have to >>>>>> be updated to throw a NPE whenever a null reference is provided instead of a value class >>>>>> instance) >>>>> >>>>> Yes, I think this is on the right track. On paths where a Q-type is needed >>>>> we do a null check. That's the Java way. >>>>> >>>>>> - null references are likely to be an issue for JIT optimizations like passing values in registers >>>>>> when a method is invoked. The proposed solution is to only allow null references for value classes >>>>>> in legacy code, by detecting them and blocking them when leaking to migrated code. The >>>>>> detection can be done at invocation time, when a mismatch between the signature expected >>>>>> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) >>>>> >>>>> At some point, a polluting null might reach code that "knows" there is a Q type >>>>> (and may even "know" that it goes in an xmm register). That's the point where >>>>> an NPE should be thrown. In some cases, a deopt might be appropriate, to >>>>> correctly order the NPE by executing interpreter code. >>>>> >>>>> Note that this combination of techniques does not Q-descriptors. The lack >>>>> of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you >>>>> have to execute a little further before you get to code which "knows" that >>>>> the null is illegal. >>>>> >>>>>> - the null reference should also be detected and blocked when it is used as a return value and the >>>>>> type of the value to be returned is a value class type >>>>> >>>>> Doing this requires (a) Q-descriptors in method returns, (b) Remi's >>>>> ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT >>>>> doesn't have to tolerate nulls: It can deopt if it hits a surprise null, >>>>> or perhaps throw an early NPE.) So, I am arguing for (c). >>>>> >>>>>> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >>>>>> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >>>>>> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >>>>>> can also help defining which experiments could be done to estimate the costs of the different additional >>>>>> checks needed to be added to existing bytecodes. >>>>> >>>>> The chart is really helpful, thanks. More comments later. >>>>> >>>>> Onward! >>>>> >>>>> ? John >>>>> >>>>> >>>> >>> >> > From frederic.parain at oracle.com Wed Jan 24 20:24:26 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 24 Jan 2018 15:24:26 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> Message-ID: Karen, Thank you for your careful review. My answers are in-lined below and I?ve uploaded an updated version of the document with the fixes: http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf > On Jan 24, 2018, at 14:32, Karen Kinnear wrote: > > Frederic, > > Many thanks for the JVMS rough draft, chart of bytecodes and what checking they need and > the mismatch chart. They are extremely helpful. > > Questions/comments on the JVMS: http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf > > 2.4 > In the paragraph that describes null related to references: > The null reference initially has no run-time type, but may be cast to any type > (implies checkcast, instanceof will continue unchanged - which is our current proposal) > The default value of a reference type is null. > - Should that be the default value of an object class type is null? > > Do we want to describe the default value of a value class type? > Perhaps we can leave these changes for Dan. The default value for the _reference_ type is null. Which is different from the default value of an instance of a value class. The content of the default value for value class is define with the defaultvalue bytecode: "All instance variables of the instance must have their default initial values (?2.3, ?2.4)." This a ?pointer" vs ?instance designed by the pointer? distinction. But it could be confusing. I?m open to better suggestions. > > 4.1/ 4.5 > From our discussion today, it sounds as though we can try Remi?s original/John?s proposal > for just tracking knowledge of a value type in the class file at two places: > 1) when declaring a class, the class access_flags would add ACC_VALUE_TYPE > 2) when declaring a field, the field access_flags would add ACC_VALUE_TYPE > (small note - can we use 0x100?) > Fixed > > 4.1 There is a comment that it is invalid to have ACC_INTERFACE and ACC_VALUE_TYPE > I believe it should also be invalid to have ACC_ABSTRACT and ACC_VALUE_TYPE Fixed > 6 invoke special > Where do we throw an exception if we have an method in a value class? Would that be verifier? > Just in case they skip verification, might it be worth throwing an exception if the resolved method is an > instance initialization method and the class is a value class - would that be an ICCE? or a NoSuchMethodError? > This is a point we should discuss with the langtools team. Today, even Valhalla Value Types have an method because javac refuses to compile a class with final fields that are not initialized in a constructor. It makes sense to forbid the method for value class, but there might be consequences I cannot see yet. > > 6 monitorenter > Run-time Exception: > ?iff object ref? -> ?if object ref? > ?monitor exit throws a IllegalMonitorStateException? -> ?monitorenter? (and ?an? before vowel Illegal?) > > Fixed Thank you. Fred > >> On Jan 24, 2018, at 11:42 AM, Frederic Parain wrote: >> >> Updated chart after Valhalla?s VM Meeting: >> >> http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-2.pdf >> >> Fred >> >>> On Jan 24, 2018, at 09:34, Frederic Parain wrote: >>> >>> I?ve uploaded a quick summary of the potential issues that can be caused >>> by a mismatch between the expected and the real nature of a class (object >>> class or value class). >>> >>> http://cr.openjdk.java.net/~fparain/L-world/ValueObjectMismatch-1.pdf >>> >>> If some cases are missing or incorrect, please let me know. >>> >>> Fred >>> >>> >>>> On Jan 23, 2018, at 19:05, Frederic Parain wrote: >>>> >>>> Updated JVMS document with a few fixes and the Q-descriptors >>>> removed (this removal changed only 3 lines!): >>>> >>>> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf >>>> >>>> No attribute to list value classes has been added yet, so there?s >>>> currently some issues for the verification. >>>> >>>> Fred >>>> >>>>> On Jan 23, 2018, at 16:25, Frederic Parain wrote: >>>>> >>>>> Hi John, >>>>> >>>>> thank you for the detailed feedback. >>>>> >>>>> The Q-descriptor is not a fundamental part of the proposal, it is just an unsatisfying >>>>> way for class files to express their expectations regarding types they think are value >>>>> class types (to differentiate them from object class types). Q-descriptors provide this >>>>> information but have drawbacks like the signature matching issue. >>>>> >>>>> Remi?s proposal is appealing because it avoids the signature matching issue. >>>>> An attribute is not the most convenient data structure for the JVM, but we can >>>>> record the information elsewhere in our meta-data. However, it seems more >>>>> brittle because the attribute can easily omitted, unless we make it mandatory >>>>> after a given class file format number, with a slightly different syntax where all >>>>> classes named in the class files have to be listed, so it can be verified. For >>>>> older class file format, the attribute would be absent and all classes are assumed >>>>> to be object classes. >>>>> >>>>> We had two brainstorming sessions. yesterday and this morning, trying to figure >>>>> out what would be the consequences of having only L-descriptors, with class >>>>> files having different assumptions regarding the real nature of a type (object class >>>>> or value class), either in the case of VBC migration or simply because of separate >>>>> compilation. Some issues are related to the calling/returning conventions for the >>>>> JIT compiled code. Some others issues are related to the class loader constraints, >>>>> and the fact that a class with the wrong assumption regarding the nature of a class >>>>> might prevent the real class from being loaded. The case where a class expects >>>>> a Value Based Class (object class type) and the class is in fact a migrated value >>>>> class seems to be OK. The case where a class expects a value class, but the >>>>> class loader loads an object class seems much more problematic to us. >>>>> >>>>> Regarding the migration of value based classes, trying to prevent null references >>>>> from leaking into migrated code seems to be a step to far. We reviewed the issue with >>>>> Karen this morning, and it doesn?t seems too dangerous to only check for null >>>>> when the reference is stored in a field or array expecting an instance of a value >>>>> class. >>>>> >>>>> Thank you, >>>>> >>>>> Fred >>>>> >>>>> >>>>>> On Jan 19, 2018, at 23:22, John Rose wrote: >>>>>> >>>>>> On Jan 16, 2018, at 12:56 PM, Frederic Parain wrote: >>>>>>> >>>>>>> Here?s an attempt to bootstrap the L-world exploration, where java.lang.Object >>>>>>> is the top type of all value classes (as discussed during the November meetings >>>>>>> in Burlington). >>>>>> >>>>>> This is excellent work, Frederic; thank you. I'm really hopeful that we >>>>>> are on the right track. >>>>>> >>>>>>> ... >>>>>>> Here?s a quick summary of the changes with some consequences on the HotSpot code: >>>>>>> - all v-bytecodes are removed except vdefault and vwithfield >>>>>> >>>>>> At some point we may want to strip the v-prefix from those survivors. No hurry. >>>>>> >>>>>>> - all bytecodes operating on an object receiver are updated to support values as well, >>>>>>> except putfield and new >>>>>> >>>>>> Yep. >>>>>> >>>>>>> - single carrier type for both instances of object classes and instances of value classes >>>>>>> - this carrier type maps to the T_OBJECT BasicType >>>>>>> - T_VALUETYPE still exists but its usage is limited (same purpose as T_ARRAY) >>>>>> >>>>>> T_ARRAY can be a confusing source of bugs. I've always wondered if it was worth it. >>>>>> >>>>>>> - qtos TosState is removed >>>>>>> - JNI: the jobject type can be used to carry either a reference to an object or an >>>>>>> array or a value. The type jvaluetype, sub-type of jobject, is used when only >>>>>>> a value class instance is expected >>>>>>> - Q?; remains the way to encode value classes in signature (fields and methods) >>>>>> >>>>>> I'd like to move towards an ACC_VALUE bit on both fields and classes. >>>>>> Again, no hurry, but (as in my previous message) I'd like to retire Q-descriptors. >>>>>> >>>>>>> - In the constant pool, the CONSTANT_CLASS_info entry type is used to store a >>>>>>> symbolic reference to either an object class or a value class >>>>>>> - the ;Q escape sequence is not used anymore in value class names >>>>>>> >>>>>>> >>>>>>> One important point of this exercise is to ensure that the migration of Value Based Classes >>>>>>> into Value Classes is possible, and doable with a reasonable complexity and costs. In addition >>>>>>> to the JVMS update (and consistent with the JVMS modifications), here?s a set of proposals >>>>>>> on how to deal with the VBC migration. >>>>>> >>>>>> I'm glad you are doing this analysis, not only because VBC migration is >>>>>> a wonderful goal, but also because I think the same analysis is necessary >>>>>> just to manage separate recompilation, even if we never decided to >>>>>> migrate a single class. >>>>>> >>>>>> In short, I see you are leaning hard on Q-descriptors, but I don't think >>>>>> you are getting enough value out of them, and they cause serious >>>>>> problems. More comments below? >>>>>> >>>>>>> >>>>>>> Migration of Value Based Classes into Value Classes: >>>>>>> - challenges: >>>>>>> - signature mismatch >>>>>> >>>>>> Goes away when/if we retire Q-descriptors! >>>>>> >>>>>>> - null >>>>>> >>>>>> Can be dealt with by assuming non-null and throwing dynamic NPEs >>>>>> as needed where Q types are in play. Also, we tolerate "polluting nulls" >>>>>> along paths where the Q/R distinction is not available, even if (at some >>>>>> point later on) we realize that it was a Q all along. Eventually, the >>>>>> polluting null will cause an NPE. >>>>>> >>>>>> (In my view, the NPE should happen later than one might prefer if it were >>>>>> a true coding error rather than a recompilation artifact. Catching polluting >>>>>> nulls early in the presence of recompilation requires too many heroics.) >>>>>> >>>>>>> - change in behavior >>>>>> >>>>>> Yes, that's the tricky part. >>>>>> >>>>>>> - proposal for signature mismatch: >>>>>>> - with LWVT, value class types in signatures are using the Q?; format >>>>>>> - legacy code is using signature with L?; format (because VBC are object classes) >>>>>>> - methods will have two signatures: >>>>>>> - true signature, which could include Q?; elements >>>>>>> - a L-ified signature where all Q?; elements are re-written with the L?; format >>>>>>> - method lookup still works by signature string comparisons >>>>>>> - the signature of the method being looked up will compared against both the >>>>>>> true and the L-ified signatures, if the looked up signature matches the L-ified >>>>>>> signature but not the true signature, it means a situation where legacy code >>>>>>> is trying to invoke migrated code has been detected, and additional work might >>>>>>> be required for the invocation (actions to be taken have to be defined) >>>>>>> - signature mismatch can also occur for fields, this is still being investigating, the >>>>>>> proposal will be updated as soon as we have a solution ready to be published >>>>>> >>>>>> This sort of thing is, for me, a rich argument against keeping Q-descriptors. >>>>>> >>>>>>> - proposal for null references leaking to migrated code >>>>>>> - having a null reference for a Value Based Class variable or field is valid in legacy code >>>>>>> but it becomes invalid when the Value Based Class has been migrated to a Value Class >>>>>>> - trying to prevent all references with a value class type to get a null value would be very >>>>>>> expensive (it would require to look at the stackmap for each assignment to a local variable) >>>>>> >>>>>> Yes. We have to tolerate polluting nulls where the Q/R distinction is unavailable. >>>>>> >>>>>>> - the proposed solution is to allow null references for local variable and expression stack slots, >>>>>>> but forbid them for fields or array elements (bytecodes operating on fields and array have to >>>>>>> be updated to throw a NPE whenever a null reference is provided instead of a value class >>>>>>> instance) >>>>>> >>>>>> Yes, I think this is on the right track. On paths where a Q-type is needed >>>>>> we do a null check. That's the Java way. >>>>>> >>>>>>> - null references are likely to be an issue for JIT optimizations like passing values in registers >>>>>>> when a method is invoked. The proposed solution is to only allow null references for value classes >>>>>>> in legacy code, by detecting them and blocking them when leaking to migrated code. The >>>>>>> detection can be done at invocation time, when a mismatch between the signature expected >>>>>>> by the caller and the real signature of the callee is detected (see signature mismatch proposal above) >>>>>> >>>>>> At some point, a polluting null might reach code that "knows" there is a Q type >>>>>> (and may even "know" that it goes in an xmm register). That's the point where >>>>>> an NPE should be thrown. In some cases, a deopt might be appropriate, to >>>>>> correctly order the NPE by executing interpreter code. >>>>>> >>>>>> Note that this combination of techniques does not Q-descriptors. The lack >>>>>> of Q-descriptors doesn't totally destroy the Q/R distinction; it just means you >>>>>> have to execute a little further before you get to code which "knows" that >>>>>> the null is illegal. >>>>>> >>>>>>> - the null reference should also be detected and blocked when it is used as a return value and the >>>>>>> type of the value to be returned is a value class type >>>>>> >>>>>> Doing this requires (a) Q-descriptors in method returns, (b) Remi's >>>>>> ValueTypes table, or (c) toleration of nulls in the interpreter. (The JIT >>>>>> doesn't have to tolerate nulls: It can deopt if it hits a surprise null, >>>>>> or perhaps throw an early NPE.) So, I am arguing for (c). >>>>>> >>>>>>> In addition to the JVMS update, here?s a chart trying to summarize the new checks that will have to >>>>>>> be added to existing bytecode when moving the vbytecodes semantic in to a* bytecodes. The categories >>>>>>> in the chart are not very precise, but we can use it as a starting point for our discussions. The chart >>>>>>> can also help defining which experiments could be done to estimate the costs of the different additional >>>>>>> checks needed to be added to existing bytecodes. >>>>>> >>>>>> The chart is really helpful, thanks. More comments later. >>>>>> >>>>>> Onward! >>>>>> >>>>>> ? John >>>>>> >>>>>> >>>>> >>>> >>> >> > From karen.kinnear at oracle.com Wed Jan 24 20:31:23 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 24 Jan 2018 15:31:23 -0500 Subject: [Nestmates] RFR: 8195828: [Nestmates] Remove leftover changes to invokespecial handling that are not needed In-Reply-To: <7837ad05-a5c5-b66e-bf43-842ea0709b72@oracle.com> References: <7837ad05-a5c5-b66e-bf43-842ea0709b72@oracle.com> Message-ID: <84C14B17-2324-49D5-A60D-64BFCEFF27C9@oracle.com> Looks good. Many thanks Karen > On Jan 22, 2018, at 1:33 AM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195828 > webrev: http://cr.openjdk.java.net/~dholmes/8195828/webrev/ > > Simple cleanup of changes not needed since we dropped use of invokespecial for nestmate support. This minimises differences with mainline version. > > Thanks, > David From karen.kinnear at oracle.com Wed Jan 24 21:11:01 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 24 Jan 2018 16:11:01 -0500 Subject: [Nestmates] RFR: 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java In-Reply-To: <5b9aaa2c-855e-4e96-d305-86b91f9f7a58@oracle.com> References: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> <40968EE4-060D-42E5-96A5-F6713419D5D6@oracle.com> <5b9aaa2c-855e-4e96-d305-86b91f9f7a58@oracle.com> Message-ID: <7E72FF66-531E-466B-964C-7F9E60FFBF64@oracle.com> David, Actually thank you for the response and the tests. The code looks good. thanks, Karen > On Jan 22, 2018, at 5:33 PM, David Holmes wrote: > > On 23/01/2018 8:27 AM, Karen Kinnear wrote: >> Forgot to ask - do you have a test for this? > > Numerous MethodHandle tests exercise this access checking logic: > > runtime/Nestmates/privateConstructors/TestMethodHandles.java > runtime/Nestmates/privateFields/TestMethodHandles.java > runtime/Nestmates/privateMethods/TestMethodHandles.java > runtime/Nestmates/privateStaticFields/TestMethodHandles.java > runtime/Nestmates/privateStaticMethods/TestMethodHandles.java > > Thanks, > David > >> thanks, >> Karen >>> On Jan 22, 2018, at 1:31 AM, David Holmes wrote: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195826 >>> webrev: http://cr.openjdk.java.net/~dholmes/8195826/webrev >>> >>> Get rid of old experimental ALLOW_NESTMATE_ACCESS support and recast directly using Reflection.areNestMates(a,b). >>> >>> Update quote of JVMS 5.4.4 access rules. >>> >>> Thanks, >>> David From john.r.rose at oracle.com Wed Jan 24 21:53:47 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Jan 2018 13:53:47 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> Message-ID: <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> On Jan 24, 2018, at 12:24 PM, Frederic Parain wrote: > >> ... >> Do we want to describe the default value of a value class type? >> Perhaps we can leave these changes for Dan. > > The default value for the _reference_ type is null. > Which is different from the default value of an instance of a value class. > The content of the default value for value class is define with the > defaultvalue bytecode: > "All instance variables of the instance must have their default initial values (?2.3, ?2.4)." > > This a ?pointer" vs ?instance designed by the pointer? distinction. > > But it could be confusing. I?m open to better suggestions. Nullability is the confusing bit. Variables which are not primitives or flattened values are inherently nullable, and default to null, they are references. Even though their class is a value class. We are convincing ourselves that this is OK for variables which are JVM stack or local variables. It may also be true for fields, in some corner cases. Basically, if classfiles get out of sync, you can witness polluting nulls in variables which are not flattened. Including fields. We could restrict the confusing pollution if we could somehow ensure that field variables whose classes are value classes are *always* flattened, even if the class defining the field "forgot" to ask for the flattening. The practicalities of classfile evolution make this hard to enforce, so I think we are stuck with nullable value fields as a corner case: Exactly when the class "forgets" to say ACC_VALUE_TYPE. (BTW, maybe it should be ACC_FLAT. So a class defined as ACC_FLAT is a value class, and a field defined ACC_FLAT loads the field class and inlines that class's layout, if it's a value class. Flatness is a linked but distinct property of classes and fields.) > >> >> 4.1/ 4.5 >> From our discussion today, it sounds as though we can try Remi?s original/John?s proposal >> for just tracking knowledge of a value type in the class file at two places: >> 1) when declaring a class, the class access_flags would add ACC_VALUE_TYPE >> 2) when declaring a field, the field access_flags would add ACC_VALUE_TYPE >> (small note - can we use 0x100?) >> > > Fixed +100 ... > >> 6 invoke special >> Where do we throw an exception if we have an method in a value class? Would that be verifier? >> Just in case they skip verification, might it be worth throwing an exception if the resolved method is an >> instance initialization method and the class is a value class - would that be an ICCE? or a NoSuchMethodError? Eventually we need to forbid object-style methods in value classes, as a local structural constraint. We can be lax to start with, since such methods will never run. Alternatively, we could allow value types to define methods but require them to be static factories. That is, they must be ACC_STATIC and must return the value type. They must also have at least one parameter, since the nullary constructor should be reserved, to denote the default value. There's no advantage to this at the JVM level, compared with regular factory methods. But such a could provide a translation strategy for the value-type version of a "new" expression. var x = Complex(0.0, -1.0); // invokestatic Complex.(DD)Complex >> > This is a point we should discuss with the langtools team. Yes; if they want to repurpose , we can do it. Or if they want to make a new token , or some some standard string, it's up to them, I think. > Today, even Valhalla Value Types have an method because javac refuses to compile a > class with final fields that are not initialized in a constructor. That's why we want to be lax today, until we can tighten up the rules. > It makes sense to forbid the method for value class, but there might be consequences > I cannot see yet. I think it's safe to remove . I suggest we *start* by removing , and let the langtools people tell us what to put back in its place. ? John From david.holmes at oracle.com Wed Jan 24 22:29:27 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 08:29:27 +1000 Subject: [Nestmates] RFR: 8195828: [Nestmates] Remove leftover changes to invokespecial handling that are not needed In-Reply-To: <84C14B17-2324-49D5-A60D-64BFCEFF27C9@oracle.com> References: <7837ad05-a5c5-b66e-bf43-842ea0709b72@oracle.com> <84C14B17-2324-49D5-A60D-64BFCEFF27C9@oracle.com> Message-ID: Thanks Karen! David On 25/01/2018 6:31 AM, Karen Kinnear wrote: > Looks good. Many thanks > > Karen > >> On Jan 22, 2018, at 1:33 AM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195828 >> webrev: http://cr.openjdk.java.net/~dholmes/8195828/webrev/ >> >> Simple cleanup of changes not needed since we dropped use of invokespecial for nestmate support. This minimises differences with mainline version. >> >> Thanks, >> David > From david.holmes at oracle.com Wed Jan 24 22:29:49 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 08:29:49 +1000 Subject: [Nestmates] RFR: 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java In-Reply-To: <7E72FF66-531E-466B-964C-7F9E60FFBF64@oracle.com> References: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> <40968EE4-060D-42E5-96A5-F6713419D5D6@oracle.com> <5b9aaa2c-855e-4e96-d305-86b91f9f7a58@oracle.com> <7E72FF66-531E-466B-964C-7F9E60FFBF64@oracle.com> Message-ID: <58a8e5a9-b666-fc1a-0ff1-fc4301a40ebb@oracle.com> Thanks Karen! David On 25/01/2018 7:11 AM, Karen Kinnear wrote: > David, > > Actually thank you for the response and the tests. > The code looks good. > > thanks, > Karen > > >> On Jan 22, 2018, at 5:33 PM, David Holmes wrote: >> >> On 23/01/2018 8:27 AM, Karen Kinnear wrote: >>> Forgot to ask - do you have a test for this? >> >> Numerous MethodHandle tests exercise this access checking logic: >> >> runtime/Nestmates/privateConstructors/TestMethodHandles.java >> runtime/Nestmates/privateFields/TestMethodHandles.java >> runtime/Nestmates/privateMethods/TestMethodHandles.java >> runtime/Nestmates/privateStaticFields/TestMethodHandles.java >> runtime/Nestmates/privateStaticMethods/TestMethodHandles.java >> >> Thanks, >> David >> >>> thanks, >>> Karen >>>> On Jan 22, 2018, at 1:31 AM, David Holmes wrote: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195826 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8195826/webrev >>>> >>>> Get rid of old experimental ALLOW_NESTMATE_ACCESS support and recast directly using Reflection.areNestMates(a,b). >>>> >>>> Update quote of JVMS 5.4.4 access rules. >>>> >>>> Thanks, >>>> David > From david.holmes at oracle.com Thu Jan 25 04:19:21 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 25 Jan 2018 04:19:21 +0000 Subject: hg: valhalla/valhalla: 4 new changesets Message-ID: <201801250419.w0P4JMtD012949@aojmv0008.oracle.com> Changeset: 209ed71e4cb8 Author: dholmes Date: 2018-01-24 23:10 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/209ed71e4cb8 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java Reviewed-by: acorn ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java Changeset: b08ab29605ef Author: dholmes Date: 2018-01-24 23:11 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b08ab29605ef 8195828: [Nestmates] Remove leftover changes to invokespecial handling that are not needed Reviewed-by: acorn ! src/hotspot/share/interpreter/linkResolver.cpp Changeset: f2ca4cada742 Author: dholmes Date: 2018-01-24 23:12 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f2ca4cada742 Adjust comment Requested-by: acorn ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 23544ad7e842 Author: dholmes Date: 2018-01-24 23:14 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/23544ad7e842 8195827: [Nestmates] jdk/internal/reflect/MethodAccessorGenerator.java should generate invokeinterface for private interface methods Reviewed-by: acorn ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java From john.r.rose at oracle.com Thu Jan 25 07:24:25 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Jan 2018 23:24:25 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> Message-ID: <84A3A79F-A5D2-446B-A99E-1E9098F6CCE0@oracle.com> On Jan 24, 2018, at 12:24 PM, Frederic Parain wrote: > > http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-2.pdf Nit: ? if_acmpeq succeeds if and only if value1 = value2 and they are not instances of a value class. ? if_acmpne succeeds if and only if value1 =? value2 or they are instances of a value class. Should be: ? if_acmpeq succeeds if and only if value1 = value2 and neither is an instance of a value class. ? if_acmpne succeeds if and only if value1 =? value2 or either is an instance of a value class. From david.simms at oracle.com Thu Jan 25 08:32:58 2018 From: david.simms at oracle.com (David Simms) Date: Thu, 25 Jan 2018 09:32:58 +0100 Subject: RFR: 8193472 [Valhalla] Interpreter should be able to return values in TLVB In-Reply-To: <219F4F0E-B91D-4FE6-AA17-5A9280BEB42F@oracle.com> References: <219F4F0E-B91D-4FE6-AA17-5A9280BEB42F@oracle.com> Message-ID: <4629827f-6889-1bab-95dd-01278c2cc2c5@oracle.com> Looks good to me, no specific comments... Sorry about the late reply. /D On 13/12/2017 9:42 p.m., Frederic Parain wrote: > Please, review this fix to improve the way values are returned by the interpreter, > using the Thread-Local Value Buffer whenever possible. The return in the TLVB > is currently disabled, because some fixes are required in JIT code. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8193472 > > Webrev: > http://cr.openjdk.java.net/~fparain/8193472/webrev.00/index.html > > Thank you, > > Fred From frederic.parain at oracle.com Thu Jan 25 21:51:49 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 25 Jan 2018 16:51:49 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> Message-ID: <0BDFD3E5-5A69-4F91-8858-A04E0B4DDE28@oracle.com> > On Jan 24, 2018, at 16:53, John Rose wrote: > > On Jan 24, 2018, at 12:24 PM, Frederic Parain wrote: >> >>> ... >>> Do we want to describe the default value of a value class type? >>> Perhaps we can leave these changes for Dan. >> >> The default value for the _reference_ type is null. >> Which is different from the default value of an instance of a value class. >> The content of the default value for value class is define with the >> defaultvalue bytecode: >> "All instance variables of the instance must have their default initial values (?2.3, ?2.4)." >> >> This a ?pointer" vs ?instance designed by the pointer? distinction. >> >> But it could be confusing. I?m open to better suggestions. > > Nullability is the confusing bit. Variables which are not primitives > or flattened values are inherently nullable, and default to null, > they are references. Even though their class is a value class. > > We are convincing ourselves that this is OK for variables which > are JVM stack or local variables. It may also be true for fields, > in some corner cases. > > Basically, if classfiles get out of sync, you can witness polluting > nulls in variables which are not flattened. Including fields. > > We could restrict the confusing pollution if we could somehow > ensure that field variables whose classes are value classes > are *always* flattened, even if the class defining the field > "forgot" to ask for the flattening. The practicalities of classfile > evolution make this hard to enforce, so I think we are stuck > with nullable value fields as a corner case: Exactly when > the class "forgets" to say ACC_VALUE_TYPE. Simply allowing non-flattened field to be null is not a viable solution because a consequence would be that the result of reading a non-initialized field would depend on wether or not the field has been flattened. With Valhalla Value Types, we were able to use the null value internally for non-initialized non-flattened field because the JVM always knew if a field were a value type or not. Unfortunately, this cannot be done in the L-world because when a non-initialized field is read, there?s no guarantee that the class of this field has been loaded yet. So, here?s a proposal that provides a semantic for null value fields that do not depend on the implementation, and without additional runtime checks for non-value fields: 1 - If a field is declared without the ACC_FLAT flag set: -> it is never flattened (even if the class is already loaded and it is a value class) -> it is OK to write null on this field -> reading the default value of this field returns null 2 - If a field is declared wit the ACC_FLAT_flag set: -> the class of this field is loaded before computing the layout of the declaring class A - If the field's class is an object class -> same semantic as in 1 is applied B - If the field's class is a value class -> writing null to this field results in setting this field to the default value of its value class -> reading the default value of this field (uninitialized) returns the default value of its value class Case 1 is the object world as we know it today, no changes, no additional runtime checks, values will be handled like objects. Case 2-A is the case where the ACC_FLAT has been mis-used on an object class. Case 2-B is the interesting value type case, and its semantic relies only on the presence of the ACC_FLAT flag, not on the decision of the JVM to flatten the field or not. Checks to intercept the null value are easy to implement, all information they need are in the field descriptor and on the execution stack. Bytecode quickening or JIT compilation will help avoiding the ACC_FLAT test completely for cases 1 and 2-A. Fred > (BTW, maybe it should be ACC_FLAT. So a class defined > as ACC_FLAT is a value class, and a field defined ACC_FLAT > loads the field class and inlines that class's layout, if it's > a value class. Flatness is a linked but distinct property of > classes and fields.) > >> >>> >>> 4.1/ 4.5 >>> From our discussion today, it sounds as though we can try Remi?s original/John?s proposal >>> for just tracking knowledge of a value type in the class file at two places: >>> 1) when declaring a class, the class access_flags would add ACC_VALUE_TYPE >>> 2) when declaring a field, the field access_flags would add ACC_VALUE_TYPE >>> (small note - can we use 0x100?) >>> >> >> Fixed > > +100 > ... >> >>> 6 invoke special >>> Where do we throw an exception if we have an method in a value class? Would that be verifier? >>> Just in case they skip verification, might it be worth throwing an exception if the resolved method is an >>> instance initialization method and the class is a value class - would that be an ICCE? or a NoSuchMethodError? > > Eventually we need to forbid object-style methods in > value classes, as a local structural constraint. We can be > lax to start with, since such methods will never run. > > Alternatively, we could allow value types to define > methods but require them to be static factories. That is, > they must be ACC_STATIC and must return the value type. > They must also have at least one parameter, since the > nullary constructor should be reserved, to denote the > default value. > > There's no advantage to this at the JVM level, compared > with regular factory methods. But such a could provide > a translation strategy for the value-type version of a > "new" expression. > > var x = Complex(0.0, -1.0); > // invokestatic Complex.(DD)Complex > > >>> >> This is a point we should discuss with the langtools team. > > Yes; if they want to repurpose , we can do it. Or if they > want to make a new token , or some some standard > string, it's up to them, I think. > >> Today, even Valhalla Value Types have an method because javac refuses to compile a >> class with final fields that are not initialized in a constructor. > > That's why we want to be lax today, until we can tighten > up the rules. > >> It makes sense to forbid the method for value class, but there might be consequences >> I cannot see yet. > > I think it's safe to remove . I suggest we *start* by > removing , and let the langtools people tell us what > to put back in its place. > > ? John From john.r.rose at oracle.com Thu Jan 25 22:48:13 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 25 Jan 2018 14:48:13 -0800 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <0BDFD3E5-5A69-4F91-8858-A04E0B4DDE28@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> <0BDFD3E5-5A69-4F91-8858-A04E0B4DDE28@oracle.com> Message-ID: <3EEE4192-3617-4E1C-8B7A-363176E1D24D@oracle.com> On Jan 25, 2018, at 1:51 PM, Frederic Parain wrote: > > Simply allowing non-flattened field to be null is not a viable > solution because a consequence would be that the result of > reading a non-initialized field would depend on wether or not > the field has been flattened. As you note below, it is possible to make the details of null processing depend on whether the *field* was declared flat or not. > With Valhalla Value Types, we were able to use the null > value internally for non-initialized non-flattened field because > the JVM always knew if a field were a value type or not. Nice trick. > Unfortunately, this cannot be done in the L-world because > when a non-initialized field is read, there?s no guarantee that > the class of this field has been loaded yet. > > So, here?s a proposal that provides a semantic for null value > fields that do not depend on the implementation, and without > additional runtime checks for non-value fields: > > 1 - If a field is declared without the ACC_FLAT flag set: > -> it is never flattened (even if the class is already loaded > and it is a value class) > -> it is OK to write null on this field > -> reading the default value of this field returns null Yes, that's what I had in mind too. > 2 - If a field is declared wit the ACC_FLAT_flag set: > -> the class of this field is loaded before computing the layout > of the declaring class > A - If the field's class is an object class > -> same semantic as in 1 is applied Yes. > B - If the field's class is a value class > -> writing null to this field results in setting this field > to the default value of its value class We have a choice here: We can also throw NPE on such writes. I think we should. There's no legitimate need for writing a null value to a flat field, I think. (But maybe there's a translation strategy, that I'm not noticing, that could use this behavior?) > -> reading the default value of this field (uninitialized) > returns the default value of its value class If you can't write null w/o NPE, then the JVM can still use the internal trick of allowing null as a sentinel for the default value. > Case 1 is the object world as we know it today, no changes, no > additional runtime checks, values will be handled like objects. > Case 2-A is the case where the ACC_FLAT has been mis-used > on an object class. > Case 2-B is the interesting value type case, and its semantic > relies only on the presence of the ACC_FLAT flag, not on the > decision of the JVM to flatten the field or not. Exactly. > Checks to intercept > the null value are easy to implement, all information they need > are in the field descriptor and on the execution stack. I agree. Resolving the CONSTANT_Fieldref to the descriptor will determine whether the *field* was declared ACC_FLAT. In that case null writes will fail and null reads (if any) can be handled in some manner convenient to the JVM. > Bytecode quickening or JIT compilation will help avoiding the ACC_FLAT > test completely for cases 1 and 2-A. Yes. ? John From david.holmes at oracle.com Mon Jan 29 06:22:09 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jan 2018 16:22:09 +1000 Subject: [Nestmates] RFR: 8195826: [Nestmates] Cleanup sun/invoke/util/VerifyAccess.java In-Reply-To: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> References: <29feeaf8-fe8f-d850-5788-b8899d9b5f80@oracle.com> Message-ID: <0b01b2a2-3763-365a-1a79-f06f7f0110de@oracle.com> For the record the code being cleaned up here was incorrect. It doesn't allow for the fact that we may encounter older classfile versions, which rely on the existing non-nestmate related access check. We need to combine the new areNestmates check with the old enclosing-class based isSamePackageMember check. New bug being filed, and new (or modified existing) test to ensure we check behaviour with older class files. David On 22/01/2018 4:31 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8195826 > webrev: http://cr.openjdk.java.net/~dholmes/8195826/webrev > > Get rid of old experimental ALLOW_NESTMATE_ACCESS support and recast > directly using Reflection.areNestMates(a,b). > > Update quote of JVMS 5.4.4 access rules. > > Thanks, > David From frederic.parain at oracle.com Mon Jan 29 19:31:56 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 29 Jan 2018 14:31:56 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <3EEE4192-3617-4E1C-8B7A-363176E1D24D@oracle.com> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <057167D9-6FEC-4BC4-88D4-2F3715796021@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> <0BDFD3E5-5A69-4F91-8858-A04E0B4DDE28@oracle.com> <3EEE4192-3617-4E1C-8B7A-363176E1D24D@oracle.com> Message-ID: John, Silently transforming null into the default value in case 2-B was just in case it could ease the handling of migrated case. If throwing NPE is OK here, it makes the semantic much cleaner. It also solves some problems we had while trying to add support for the null value in the value class? equals() method. During a brainstorming session with Karen this morning, we realized that case 2-A (ACC_FLAT flag set for an object class) should be in fact treated as an error, instead of just ignoring the flag. These two modifications makes the semantic mucho simpler and cleaner with only two cases: one where null is always valid, and one where null is never valid. So here?s a re-write of the semantic: Fields have a new access flag called ACC_NON_NULLABLE. The type of a field with the ACC_NON_NULLABLE flag set must be a value class type, otherwise an ICCE is thrown. 1 - If a field is declared without the ACC_NON_NULLABLE flag set: - this field is initialized with the null reference - it is valid to write null to this field - note: JVMs are unlikely to flatten such field 2 - If a field is declared with the ACC_NON_NULLABLE flag set: - this field is initialized with the default value of this field?s value class - writing null to this field causes a NPE - JVMs are encouraged to flatten such field This semantic makes much more sense because being non-nullable is a property of the container more than a property of the field?s type. Fred > On Jan 25, 2018, at 17:48, John Rose wrote: > > On Jan 25, 2018, at 1:51 PM, Frederic Parain wrote: >> >> Simply allowing non-flattened field to be null is not a viable >> solution because a consequence would be that the result of >> reading a non-initialized field would depend on wether or not >> the field has been flattened. > > As you note below, it is possible to make the details > of null processing depend on whether the *field* was > declared flat or not. > >> With Valhalla Value Types, we were able to use the null >> value internally for non-initialized non-flattened field because >> the JVM always knew if a field were a value type or not. > > Nice trick. > >> Unfortunately, this cannot be done in the L-world because >> when a non-initialized field is read, there?s no guarantee that >> the class of this field has been loaded yet. >> >> So, here?s a proposal that provides a semantic for null value >> fields that do not depend on the implementation, and without >> additional runtime checks for non-value fields: >> >> 1 - If a field is declared without the ACC_FLAT flag set: >> -> it is never flattened (even if the class is already loaded >> and it is a value class) >> -> it is OK to write null on this field >> -> reading the default value of this field returns null > > Yes, that's what I had in mind too. > >> 2 - If a field is declared wit the ACC_FLAT_flag set: >> -> the class of this field is loaded before computing the layout >> of the declaring class >> A - If the field's class is an object class >> -> same semantic as in 1 is applied > > Yes. > >> B - If the field's class is a value class >> -> writing null to this field results in setting this field >> to the default value of its value class > > We have a choice here: We can also throw NPE on > such writes. I think we should. There's no legitimate > need for writing a null value to a flat field, I think. > > (But maybe there's a translation strategy, that I'm not > noticing, that could use this behavior?) > >> -> reading the default value of this field (uninitialized) >> returns the default value of its value class > > If you can't write null w/o NPE, then the JVM can > still use the internal trick of allowing null as a > sentinel for the default value. > >> Case 1 is the object world as we know it today, no changes, no >> additional runtime checks, values will be handled like objects. >> Case 2-A is the case where the ACC_FLAT has been mis-used >> on an object class. >> Case 2-B is the interesting value type case, and its semantic >> relies only on the presence of the ACC_FLAT flag, not on the >> decision of the JVM to flatten the field or not. > > Exactly. > >> Checks to intercept >> the null value are easy to implement, all information they need >> are in the field descriptor and on the execution stack. > > I agree. Resolving the CONSTANT_Fieldref to the descriptor > will determine whether the *field* was declared ACC_FLAT. > In that case null writes will fail and null reads (if any) can be > handled in some manner convenient to the JVM. > >> Bytecode quickening or JIT compilation will help avoiding the ACC_FLAT >> test completely for cases 1 and 2-A. > > Yes. > > ? John From john.r.rose at oracle.com Mon Jan 29 20:42:49 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Jan 2018 12:42:49 -0800 Subject: optimizing acmp in L-World Message-ID: <47625659-9B0E-481C-B755-4C5C4E2DE23C@oracle.com> Tobias, Roland, and I had a chat in Santa Clara last week about optimizing the acmp operation in the JVM. Here are my notes on it. Background: The acmp operation, also known as reference comparison, is overloaded in L-World to handle values as well, with a specific semantics of returning false if either operand is a value (similar to NaN behavior for fcmp). The rationale for this is that acmp is reference comparison, even in L-World, and since values have no references, they can never be equal as references. (Alternatively, it is *as if* both operands were converted *to references* before the acmp operation, which means that either operand, if it is a value, *would be* boxed to a reference value, which then, being a new reference, is automatically unequal to any other reference. This tricky account may be appealing in some circumstances.) OK, so how do we make it fast? Ideally, we would like to strength-reduce the enhanced acmp instruction down to the original acmp instruction, which after all is just a single instruction (such as cmpq) on all platforms. The first thing to notice, before going into details, is that in L-world all Q-values are buffered in the interpreter. This means that, at least for interpreter-generated values, all values can be treated as physical pointers, even if they are logically Q-values. (Crib sheet: In L-world, all kinds of values except primitives are formally carried by L-values, under L-descriptors. True references can be referred to as R-values of R-type, reference type, or object class. New value types are referred to as Q-values of Q-type, value type, or value class. When you don't know what you have, you can say it's a U-type, which just like a Q-type or R-type is carried by an L-value under an L-descriptor.) This means that the old acmp semantics are almost correct, in many cases. If you have two L-values and do a pointer comparison on their physical pointers, and if the pointers differ, you are done. If the physical pointers compare equal, then there is one more thing you have to do: Make sure that the L-value carried by both physical pointers is in fact a reference, an R-value. So the logic looks like this, and the new semantics are in the second "if" statement: bool new_acmp(ptr x, ptr y) { if (!old_acmp(x, y)) return false; // x != y => false if (is_value_ptr(x)) return false; // x.is_value => false return true; } bool old_acmp(ptr x, ptr y) { return x == y; // cmpq etc. } Note that since acmp is symmetric, the JVM has the option to silently test either x or y for "is_value_ptr" if the two physical pointers compare equal. This leads immediately to the first set of optimizations, which probably are enough to get us where we want to go. (There is a second set we can add later.) All the JVM has to do is prove or detect that one or the other physical pointer either *is certainly* a Q-value, or *is certainly not* a Q-value. If either physical pointer is certainly a Q-value, then the new_acmp instruction is a constant false. If either physical pointer is certainly not a Q-value, then the new_acmp instruction strength reduces to the old_acmp instruction. The strength reduction to false can be done in any place where the type of either operand is known to be a Q-type. The interpreter doesn't track types, and the acmp instruction isn't resolved so it can't be quickened to a type context, but the JIT has lots of type information. Thus, if either operand of acmp is statically known (or accurately speculated) to be a value type, then the acmp instruction constant folds to false. Likewise, if either operand is known to be an R-type (true reference) the acmp may be strength reduced to a simple reference comparison. This also is likely to happen in the JIT. It also happens in the interpreter in the acmp_null instruction, where (obviously) the second operand is a reference (i.e., null). (Note that the type Object is a U-type in L-world, so Object-to-Object comparisons such as are found in generic collection code do not benefit from this optimization. More later on that.) The JIT can also track, in its profile, whether various instructions "see" only Q-values or only R-values. (The classic HotSpot already tracks "sightings" of null for similar purposes.) In that case, speculative narrowings (only Q-types or only R-types) can be used to short circuit new_acmp down to old_acmp. This is useful because the speculation can sometimes be verified out of a loop body, where the actual acmp instruction is executed in a loop. Remember that the JIT can choose which operand of acmp to test for value-ness; if it chooses a loop invariant, and the invariant is always Q or always R, then the acmp inside the loop folds up, no matter what the dynamic value of the other operand. For that matter, even if speculation fails, loop unswitching can get to a similar result, at the cost of two copies of the loop. So, in many cases, contextual information can allow the JVM to fold up new_acmp to old_acmp or constant false. In cases such folding fails, there is as simple trick which can make things easier. Recall that folding fails when *both* operands are statically U-types, *neither* operand folding to a Q-type or R-type. In that case, the JVM must pick one operand or the other (it doesn't matter which) and perform the is_value_ptr operation on it, in such a way that the result of that operand affects the final result in the correct way. A naive implementation of new_acmp adds an extra test-and-branch to fold in the is_value_ptr test, but a clever might be able to avoid it. Suppose there is a branch free technique for implementing is_value_ptr, such as extracting a bit from the physical pointer to the U-value, or (after a null check) extracting a bit from the physical pointer of the class metadata pointer in the value's header, or (after two indirections) extracting a bit from the structure of the class metadata. (Mr. Simm's prototype puts such a bit in the metadata pointer, in the object header.) If such a bit can be obtained in a branch-free manner, then it can be used to perturb the result of the old_acmp in a useful manner. For example: bool new_acmp(ptr x, ptr y) { if (x == null) return y == null; int bit = (x->class_in_header & Q_TYPE_BIT); ptr x1 = x | swar_broadcast_bit(bit != 0); return old_acmp(x1, y); } int swar_broadcast_bit(bool z) { return z ? -1 : 0; // use ALU ops } The idea is to extract a bit which signals the presence of a Q-type (in either operand) and use it to "mess up" the equality comparison, using and, or, or xor as needed. This perturbation technique has two costs: First, it requires a null check (unless the Q-bit is in the actual physical reference). Second, it requires an ALU operation or two to spread the perturbation. But these costs will probably be negligible, except (perhaps) in very tight loops in generic code. Generic code loops performing frequent acmp operations on untyped (Object) operands will need to perform extra null checks and/or value/reference detections if they are not already present (by luck) in the loop context. In this case, loop unswitching may be useful. There is one more contextual operation which may be helpful in such cases, if all else fails (and loop unswitching is not desirable). Honestly, I haven't seen any real-world code yet that needs it, but it is comforting to have as a fall-back. The idea is this: If the acmp is contextually followed by a call to Object.equals, in the usual Legacy Idiom For Equality (L.I.F.E.), then there is one more trick we can play. We'd like to force the new_acmp down to an old_acmp in these cases. Can we? Here's the choice: bool dutiful_life(ptr x, ptr y) { if (new_acmp(x, y)) return true; return x->Object_equals(y); } bool clever_life(ptr x, ptr y) { if (old_acmp(x, y)) return true; return x->Object_equals(y); } Note that the only semantic difference between old_acmp and new_acmp arises when *both* operands are the *same* value. (Work out the cases: In every other case, the simple pointer comparison detects the difference and produces the correct "false" answer.) Thus, in the L.I.F.E., the only case where old_acmp gives the wrong answer produces an immediate answer of "true", instead of following up with a call to x.equals(x) on the Q-value. To put it in a nutshell, the only difference between dutiful_life and clever_life is that the former always calls Object::equals if either operand is a value, and the the latter calls Object::equals in a subset of those cases (when the physical pointers differ). When the physical pointers do *not* differ, there is no call to Object::equals. But clever_life always delivers the same answer as dutiful_life. So is there a problem? Not much, although it requires us to treat Object::equals as an intrinsic with some predictable semantics. The crucial inside that allows us to adopt clever_life is that, if you call x.equals(x) on a non-null x, the result must always be true. Now, this is not enforced by the JVM, but it is clearly documented in the API specification for Object::equals, and lots of stuff would be already broken if that were ever false. Thus, if we are willing to rule out implementations of Object::equals for which a value can ever compare *not equal* to itself, then we can substitute clever_life for dutiful_life. We also have to allow one more thing: That we can silently drop calls to equals (at least in the context of L.I.F.E.) when the JVM can prove that the contract of equals allows the JVM to predict the outcome. This means that if you put side effects (like print statements) into an equals method on a value type, you might not see the side effects, after the JVM has optimized things. This corner case may require further thought in order to straighten it out. Note that L.I.F.E. is frequently found in generic code, where instead of operating on Object values it operates on type parameter types. (The JVM just sees Object, after erasure.) In that case, if the JVM were to specialize the generic code separately for some types (such as value types), along the lines of the template class proposals, then the L.I.F.E. code would fold up in the JIT using the rules given at the top of this note. The generic expression "a == b", where a or b was a value of a specialized type parameter T, would fold up to false in every specialization where T was a Q-type. Likewise, as noted above, if L.I.F.E. is applied to a true R-type (or specialized to such a type), then any new_acmp on that type can be short-circuited to the faster old_acmp. All in all, it appears that the cost of the new acmp semantics can, for all practical purposes, be pushed down into the noise. ? John From david.holmes at oracle.com Tue Jan 30 04:43:32 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 30 Jan 2018 04:43:32 +0000 Subject: hg: valhalla/valhalla: 8193408: [Nestmates] Update Class.getNestMembers to allow for duplicates Message-ID: <201801300443.w0U4hWPi021742@aojmv0008.oracle.com> Changeset: 64231bbc1346 Author: dholmes Date: 2018-01-29 23:38 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/64231bbc1346 8193408: [Nestmates] Update Class.getNestMembers to allow for duplicates Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/Class.java From srikanth.adayapalam at oracle.com Tue Jan 30 09:19:54 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Tue, 30 Jan 2018 09:19:54 +0000 Subject: hg: valhalla/valhalla: Scanner, parser, semantic analysis and attribution support for value types Message-ID: <201801300919.w0U9Jtg7018815@aojmv0008.oracle.com> Changeset: 8d76e47a91e7 Author: sadayapalam Date: 2018-01-30 14:45 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8d76e47a91e7 Scanner, parser, semantic analysis and attribution support for value types ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/jdk.compiler/share/classes/com/sun/source/tree/NewClassTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/tools/javac/diags/examples.not-yet.txt + test/langtools/tools/javac/diags/examples/ValuesNotSupported.java + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.java + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.out + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.java + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.out + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.java + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.out + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.java + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.java + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.out + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.java + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.out + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.java + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.out + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.java + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.out + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.java + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.out + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.java + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.out + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.java + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.out + test/langtools/tools/javac/valhalla/lworld-values/CheckSuperCompileOnly.java + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.out + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.java + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.out + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.java + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.out + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.java + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.out + test/langtools/tools/javac/valhalla/lworld-values/Point.java From srikanth.adayapalam at oracle.com Tue Jan 30 09:21:47 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 30 Jan 2018 14:51:47 +0530 Subject: hg: valhalla/valhalla: Scanner, parser, semantic analysis and attribution support for value types In-Reply-To: <201801300919.w0U9Jtg7018815@aojmv0008.oracle.com> References: <201801300919.w0U9Jtg7018815@aojmv0008.oracle.com> Message-ID: Hello, The commit below is the record of the change set I pushed to valhalla "exp" branch that contains the javac changes for scanner, parser, semantic analysis and attribution support for value types. Most of this is leveraged from the existing prototype and tweaked for the present work. No code generation support exists at the moment. I will look into it now. See below for the summary of changes and a couple of questions. Summary of changes: ??? - Tag a type declaration as being a value type with __ByValue modifier (>= JDK11) ??? - Value types may not declare a super class not even j.l.O ??? - Value class declarations and their instance fields must be final. ??? - Value types may not declare fields of their own types either directly or indirectly. ??? - Null cannot be assigned to value types ??? - Null cannot be casted to or compared with value types. ??? - Support for static value factories and value instance creation via __MakeDefault() ??? - Values have no instance lock and so may not be synchronized upon. ??? - Values have no identity and consequently the method java.lang.System.identityHashCode ????? may not be invoked on them and ??? - The following methods from j.l.O are not allowed on value receivers: ??????? - clone() ??????? - finalize() ??????? - wait() ??????? - wait(long), ??????? - wait(long, int) ??????? - notify ??????? - notifyAll ??? - Value instances may not be compared with == or != ??? - Tests for the above restrictions. Questions: 1.??? ATM, javac forbids comparison of values using != or ==. This behavior is simply brought forward from the original valhalla implementation. Is this what we want in the present prototype ? (in the context of acmp performance characterization ?) 2. The support in the parser allows inner class to be declared as __ByValue. Do we want to restrict values to top level classes ? I seem to recall this being suggested a while ago - but I am unable to dig up the context. Thanks! Srikanth On Tuesday 30 January 2018 02:49 PM, srikanth.adayapalam at oracle.com wrote: > Changeset: 8d76e47a91e7 > Author: sadayapalam > Date: 2018-01-30 14:45 +0530 > URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8d76e47a91e7 > > Scanner, parser, semantic analysis and attribution support for value types > > ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java > ! src/jdk.compiler/share/classes/com/sun/source/tree/NewClassTree.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java > ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java > ! test/langtools/tools/javac/diags/examples.not-yet.txt > + test/langtools/tools/javac/diags/examples/ValuesNotSupported.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckSuperCompileOnly.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.out > + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.java > + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.out > + test/langtools/tools/javac/valhalla/lworld-values/Point.java > From karen.kinnear at oracle.com Tue Jan 30 17:28:11 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 30 Jan 2018 12:28:11 -0500 Subject: hg: valhalla/valhalla: Scanner, parser, semantic analysis and attribution support for value types In-Reply-To: References: <201801300919.w0U9Jtg7018815@aojmv0008.oracle.com> Message-ID: Srikanth, I have not yet had a time to look through the code, but I wanted to get back to you right away. First - many many thanks for doing this so quickly and for asking for feedback at this early phase. Some clarifications to the list below. My apologies if I incorrectly specified some to you. Thank you for your understanding A we have been evolving some key issues such as how to deal with signatures and nullability. So this is a good time to touch base. Also - can you touch base with Mr Simms on the repos - my understanding was that the ?exp? branch was for independent performance experiments based on JDK 11 without value types support, and he was going to create a new branch ?name TBD? for our joint prototype. > On Jan 30, 2018, at 4:21 AM, Srikanth wrote: > > > Hello, > > The commit below is the record of the change set I pushed to valhalla "exp" branch > that contains the javac changes for scanner, parser, semantic analysis and attribution > support for value types. Most of this is leveraged from the existing prototype > and tweaked for the present work. > > No code generation support exists at the moment. I will look into it now. > See below for the summary of changes and a couple of questions. > > Summary of changes: > > - Tag a type declaration as being a value type with __ByValue modifier (>= JDK11) yes > - Value types may not declare a super class not even j.l.O current proposal is that a value type must explicitly declare j.l.O as the super class > - Value class declarations and their instance fields must be final. yes > - Value types may not declare fields of their own types either directly or indirectly. yes > - Null cannot be assigned to value types This is a very new proposal - still in discussion http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003721.html Proposal is to add in the classfile the ACC_NON_NULLABLE flag for FieldInfo ? I do not know what the language support should be for a prototype? ? keyword? annotation? Needs a langtools team discussion, perhaps before that all gets sorted out stick with the keywords like the rest of the prototype, e.g. __NonNullable If the field is declared with the ACC_NON_NULLABLE, then writing to this field at runtime with throw and NPE. Given that it is illegal to use this flag for an object class (vs. a value class) javac could catch both the use of this class for an object class, and catch assigning these fields to null. Let us know if you see a problem with this approach for prototyping > - Null cannot be casted to or compared with value types. Changed: null can be cast to a value type or compared with a value type (we left the semantics of checkcast and instanceof unchanged) (see below for comparison discussion) > - Support for static value factories and value instance creation via __MakeDefault() > - Values have no instance lock and so may not be synchronized upon. clarify: it is illegal to declare a non-static synchronized method for a value class > - Values have no identity and consequently the method java.lang.System.identityHashCode > may not be invoked on them and I had assumed that java.lang.System.identityHashCode() would be revised to throw an exception at runtime for values, not that javac would catch this > - The following methods from j.l.O are not allowed on value receivers: > - clone() > - finalize() > - wait() > - wait(long), > - wait(long, int) > - notify > - notifyAll Actually they all are - we will be rewriting the j.l.O methods to throw runtime errors if this happens, so we do not need javac to disallow this (we will run into this at runtime due to inheritance when passing an Object or interface and the receiver is a value instance - so we have to do a runtime check anyway) > - Value instances may not be compared with == or != The proposal was that value instances MAY be compared with if_acmpeq/if_acmp_ne, and the bytecode will return FALSE if either argument is a value type This presupposes a model in which ?most? code uses a check of ==/!=, null check, .equals() check > - Tests for the above restrictions. > > Questions: > > 1. ATM, javac forbids comparison of values using != or ==. This behavior is simply > brought forward from the original valhalla implementation. Is this what we want in > the present prototype ? (in the context of acmp performance characterization ?) > > 2. The support in the parser allows inner class to be declared as __ByValue. Do we want > to restrict values to top level classes ? I seem to recall this being suggested a while > ago - but I am unable to dig up the context. I added this to the list of open design questions - I think that is a language choice, I don?t know why the JVM would care since today it knows nothing really about top level vs inner classes. Also brings up the question of withfield (renamed) and where it is legal to call it - explicit factories, any method in the value class itself, nestmates? thanks so much, Karen > > Thanks! > Srikanth > > > On Tuesday 30 January 2018 02:49 PM, srikanth.adayapalam at oracle.com wrote: >> Changeset: 8d76e47a91e7 >> Author: sadayapalam >> Date: 2018-01-30 14:45 +0530 >> URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8d76e47a91e7 >> >> Scanner, parser, semantic analysis and attribution support for value types >> >> ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java >> ! src/jdk.compiler/share/classes/com/sun/source/tree/NewClassTree.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java >> ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java >> ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java >> ! test/langtools/tools/javac/diags/examples.not-yet.txt >> + test/langtools/tools/javac/diags/examples/ValuesNotSupported.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckSuperCompileOnly.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.out >> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.java >> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.out >> + test/langtools/tools/javac/valhalla/lworld-values/Point.java >> > From karen.kinnear at oracle.com Tue Jan 30 22:38:54 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 30 Jan 2018 17:38:54 -0500 Subject: Update Valhalla LWorld Value Types proposal Message-ID: Feedback welcome. Updates include changes in signature handling - all ?LFoo;? and nullability handling - see Frederic?s summary: http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003721.html http://cr.openjdk.java.net/~acorn/LWorldValueTypes.pdf thanks, Karen From david.holmes at oracle.com Wed Jan 31 00:10:28 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 31 Jan 2018 00:10:28 +0000 Subject: hg: valhalla/valhalla: Fixed typo Message-ID: <201801310010.w0V0AU9P028484@aojmv0008.oracle.com> Changeset: e95006f30c9d Author: dholmes Date: 2018-01-30 19:05 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e95006f30c9d Fixed typo ! src/java.base/share/classes/java/lang/Class.java From david.holmes at oracle.com Wed Jan 31 04:54:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 31 Jan 2018 14:54:40 +1000 Subject: [Nestmates] RFR: 8196320: [Nestmates] Restore the old enclosing-class based isSamePackageMember check in sun/invoke/util/VerifyAccess.java Message-ID: <7880cf5b-8f17-cc43-ce91-1285bcaaac8b@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8196320 webrev: http://cr.openjdk.java.net/~dholmes/8196320/webrev/ I've restored the original enclosing-class check and the isSamePackageMember method, but renamed it to areNestMates. It will first do the real Reflection.areNestMates check, and if that fails fall-back to the pre-nestmate enclosing class check. I've added a test under runtime/Nestmates/legacy (where I'll accumulate tests that check legacy code still works after the nestmate changes - for specific areas like this.) The test will need tweaking once we bump the version to 11 (unfortunately there's no system property that reports the classfile version AFAICS). Thanks, David From srikanth.adayapalam at oracle.com Wed Jan 31 05:43:11 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 31 Jan 2018 11:13:11 +0530 Subject: hg: valhalla/valhalla: Scanner, parser, semantic analysis and attribution support for value types In-Reply-To: References: <201801300919.w0U9Jtg7018815@aojmv0008.oracle.com> Message-ID: Hi Karen, Thanks for your comments - There is no need for apologizing and such ! I am not looking for a fully evolved specification and am happy to accommodate any changes you require or address any misunderstandings on my part that you call out :) Some of the issues you raise though require further discussion and I am pulling up and enumerating these below: (In summary ATM (1) through (6) below look as though they don't call for a change - But I will wait for any contrary opinions. I'll study (7) and (8) and follow up suitably.) (1) Branch to use: I have asked David Simms for clarification, but I based my decision to push to "exp" on http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003663.html. After hearing from David, I'll take suitable follow up actions (including nothing) ---- (2) Value types may not declare a super class not even j.l.O: Please note: In the commit I pushed, value classes *do* extend j.l.O, it is just that they can't explicitly declare an extends clause even if that only mentions j.l.O This is consistent with (a) How in the original valhalla prototype, value types extend java.lang.__Value, but cannot mention an explicit super type in the extends clause. (b) This is also consistent with how all annotation types automatically implement java.lang.annotation.Annotation but are not allowed to specify an implements clause in the annotation type declaration site. (c) This is also consistent with how all enum types implicitly automatically extend java.lang.Enum, but cannot expressly extend it. (d) Also consistent with how all interfaces have j.l.O as a super type but this cannot be expressed in source. For these reasons I am inclined to think we should leave this matter as is, but can be convinced if I am found to overlook some points. ------------ (3) "Values have no instance lock and so may not be synchronized upon" Clarification: (a) A value type may not declare an instance method that has the modifier synchronized AND (b) A value instance may not be used to furnish the mutual exclusion lock for a synchronized statement. (Already done in the prototype) ----- (4) Values have no identity and consequently the method java.lang.System.identityHashCode may not be invoked on them: You wrote: I had assumed that java.lang.System.identityHashCode() would be revised to throw an exception at runtime for values, not that javac would catch this Certainly a runtime check and throw would be required at j.l.S.identityHashCode(), but it would feel very "unlike Java" to NOT catch this error statically where possible. I agree not all cases could be caught at compile time and so a second line defense would be required at runtime. ------ (5) The following methods from j.l.O are not allowed on value receivers:? clone(), finalize(), wait(), wait(long), wait(long, int), notify, notifyAll You wrote: Actually they all are - we will be rewriting the j.l.O methods to throw runtime errors if this happens, so we do not need javac to disallow this (we will run into this at runtime due to inheritance when passing an Object or interface and the receiver is a value instance - so we have to do a runtime check anyway) I understand how values may "leak" into places where they cannot be discerned to be values statically and hence the rationale for doing a runtime check anyway and rewriting j.l.O methods to throw runtime errors when the receiver happens to be a value instance - but not diagnosing this where it is possible to do so statically in javac would again similar to (4) above be very unlike Java - That is to defer errors to runtime where they can be caught and reported right away at compile time. (6) Clarification: I expect Javac would issue a withfield instruction only from the static value factory associated with the value type and nowhere else. As a matter of fact attempt to assign to an instance field of a value type anywhere else would trigger a compile time error about final field being modified, ------ (7) Null assignment to values, casting null to values and null comparison against values: Thanks for your comments and the pointer to recent discussion. I'll study these in detail and make suitable changes or follow up with requests for additional clarifications. --- (8) Value instances may not be compared with == or != You wrote: The proposal was that value instances MAY be compared with if_acmpeq/if_acmp_ne, and the bytecode will return FALSE if either argument is a value type This presupposes a model in which ?most? code uses a check of ==/!=, null check, .equals() check Is this true for source code where it can be discerned by the compiler that one or both of the operands of == or != is a value type ??? http://cr.openjdk.java.net/~jrose/values/values-0.html does foresee different semantics for == and != on values, including component-wise == comparison or invoking equals method, but I am not sure where we stand. Thanks! Srikanth On Tuesday 30 January 2018 10:58 PM, Karen Kinnear wrote: > Srikanth, > > I have not yet had a time to look through the code, but I wanted to get back to you right away. > > First - many many thanks for doing this so quickly and for asking for feedback at this > early phase. > > Some clarifications to the list below. My apologies if I incorrectly specified some to you. > Thank you for your understanding A we have been evolving some key issues such as how to > deal with signatures and nullability. So this is a good time to touch base. > > Also - can you touch base with Mr Simms on the repos - my understanding was that > the ?exp? branch was for independent performance experiments based on JDK 11 > without value types support, and he was going to create a new branch ?name TBD? for our joint > prototype. > >> On Jan 30, 2018, at 4:21 AM, Srikanth wrote: >> >> >> Hello, >> >> The commit below is the record of the change set I pushed to valhalla "exp" branch >> that contains the javac changes for scanner, parser, semantic analysis and attribution >> support for value types. Most of this is leveraged from the existing prototype >> and tweaked for the present work. >> >> No code generation support exists at the moment. I will look into it now. >> See below for the summary of changes and a couple of questions. >> >> Summary of changes: >> >> - Tag a type declaration as being a value type with __ByValue modifier (>= JDK11) > yes >> - Value types may not declare a super class not even j.l.O > current proposal is that a value type must explicitly declare j.l.O as the super class >> - Value class declarations and their instance fields must be final. > yes >> - Value types may not declare fields of their own types either directly or indirectly. > yes >> - Null cannot be assigned to value types > This is a very new proposal - still in discussion > > http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003721.html > > Proposal is to add in the classfile the ACC_NON_NULLABLE flag for FieldInfo > ? I do not know what the language support should be for a prototype? > ? keyword? annotation? Needs a langtools team discussion, perhaps > before that all gets sorted out stick with the keywords like the rest of the prototype, > e.g. __NonNullable > > If the field is declared with the ACC_NON_NULLABLE, then writing to this field > at runtime with throw and NPE. > Given that it is illegal to use this flag for an object class (vs. a value class) > javac could catch both the use of this class for an object class, and catch > assigning these fields to null. > > Let us know if you see a problem with this approach for prototyping > >> - Null cannot be casted to or compared with value types. > Changed: null can be cast to a value type or compared with a value type > (we left the semantics of checkcast and instanceof unchanged) > (see below for comparison discussion) > >> - Support for static value factories and value instance creation via __MakeDefault() >> - Values have no instance lock and so may not be synchronized upon. > clarify: it is illegal to declare a non-static synchronized method for a value class > >> - Values have no identity and consequently the method java.lang.System.identityHashCode >> may not be invoked on them and > I had assumed that java.lang.System.identityHashCode() would be revised to throw an exception at runtime for values, not that javac would catch this >> - The following methods from j.l.O are not allowed on value receivers: >> - clone() >> - finalize() >> - wait() >> - wait(long), >> - wait(long, int) >> - notify >> - notifyAll > Actually they all are - we will be rewriting the j.l.O methods to throw runtime errors if this happens, > so we do not need javac to disallow this > (we will run into this at runtime due to inheritance when passing an Object or interface and the > receiver is a value instance - so we have to do a runtime check anyway) >> - Value instances may not be compared with == or != > The proposal was that value instances MAY be compared with if_acmpeq/if_acmp_ne, > and the bytecode will return FALSE if either argument is a value type > This presupposes a model in which ?most? code uses a check of ==/!=, null check, .equals() check > >> - Tests for the above restrictions. >> >> Questions: >> >> 1. ATM, javac forbids comparison of values using != or ==. This behavior is simply >> brought forward from the original valhalla implementation. Is this what we want in >> the present prototype ? (in the context of acmp performance characterization ?) >> 2. The support in the parser allows inner class to be declared as __ByValue. Do we want >> to restrict values to top level classes ? I seem to recall this being suggested a while >> ago - but I am unable to dig up the context. > I added this to the list of open design questions - I think that is a language choice, I don?t > know why the JVM would care since today it knows nothing really about top level vs > inner classes. > Also brings up the question of withfield (renamed) and where it is legal to call it - > explicit factories, any method in the value class itself, nestmates? > > thanks so much, > Karen > > >> Thanks! >> Srikanth >> >> >> On Tuesday 30 January 2018 02:49 PM, srikanth.adayapalam at oracle.com wrote: >>> Changeset: 8d76e47a91e7 >>> Author: sadayapalam >>> Date: 2018-01-30 14:45 +0530 >>> URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8d76e47a91e7 >>> >>> Scanner, parser, semantic analysis and attribution support for value types >>> >>> ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java >>> ! src/jdk.compiler/share/classes/com/sun/source/tree/NewClassTree.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java >>> ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java >>> ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java >>> ! test/langtools/tools/javac/diags/examples.not-yet.txt >>> + test/langtools/tools/javac/diags/examples/ValuesNotSupported.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSuperCompileOnly.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.out >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.java >>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.out >>> + test/langtools/tools/javac/valhalla/lworld-values/Point.java >>> > From forax at univ-mlv.fr Wed Jan 31 10:54:39 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 31 Jan 2018 11:54:39 +0100 (CET) Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> <0BDFD3E5-5A69-4F91-8858-A04E0B4DDE28@oracle.com> <3EEE4192-3617-4E1C-8B7A-363176E1D24D@oracle.com> Message-ID: <1756463780.140684.1517396079851.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Frederic Parain" > ?: "John Rose" > Cc: "valhalla-dev" > Envoy?: Lundi 29 Janvier 2018 20:31:56 > Objet: Re: Moving from VVT to the L-world value types (LWVT) > John, > > Silently transforming null into the default value in case 2-B was > just in case it could ease the handling of migrated case. If throwing > NPE is OK here, it makes the semantic much cleaner. It also solves > some problems we had while trying to add support for the null > value in the value class? equals() method. > > During a brainstorming session with Karen this morning, we realized > that case 2-A (ACC_FLAT flag set for an object class) should be in > fact treated as an error, instead of just ignoring the flag. Which means that changing a value type to a reference type is not a backward compatible change, i'm Ok with that. > > These two modifications makes the semantic mucho simpler and > cleaner with only two cases: one where null is always valid, and > one where null is never valid. > > So here?s a re-write of the semantic: > > Fields have a new access flag called ACC_NON_NULLABLE. > > The type of a field with the ACC_NON_NULLABLE flag set must > be a value class type, otherwise an ICCE is thrown. > > 1 - If a field is declared without the ACC_NON_NULLABLE flag set: > - this field is initialized with the null reference > - it is valid to write null to this field > - note: JVMs are unlikely to flatten such field > > 2 - If a field is declared with the ACC_NON_NULLABLE flag set: > - this field is initialized with the default value of this field?s value class > - writing null to this field causes a NPE > - JVMs are encouraged to flatten such field > > This semantic makes much more sense because being non-nullable > is a property of the container more than a property of the field?s type. > > Fred I agree about the semantics, the name of the flag is wrong, it should be ACC_FLAT_THUS_NON_NULLABLE :) R?mi > >> On Jan 25, 2018, at 17:48, John Rose wrote: >> >> On Jan 25, 2018, at 1:51 PM, Frederic Parain wrote: >>> >>> Simply allowing non-flattened field to be null is not a viable >>> solution because a consequence would be that the result of >>> reading a non-initialized field would depend on wether or not >>> the field has been flattened. >> >> As you note below, it is possible to make the details >> of null processing depend on whether the *field* was >> declared flat or not. >> >>> With Valhalla Value Types, we were able to use the null >>> value internally for non-initialized non-flattened field because >>> the JVM always knew if a field were a value type or not. >> >> Nice trick. >> >>> Unfortunately, this cannot be done in the L-world because >>> when a non-initialized field is read, there?s no guarantee that >>> the class of this field has been loaded yet. >>> >>> So, here?s a proposal that provides a semantic for null value >>> fields that do not depend on the implementation, and without >>> additional runtime checks for non-value fields: >>> >>> 1 - If a field is declared without the ACC_FLAT flag set: >>> -> it is never flattened (even if the class is already loaded >>> and it is a value class) >>> -> it is OK to write null on this field >>> -> reading the default value of this field returns null >> >> Yes, that's what I had in mind too. >> >>> 2 - If a field is declared wit the ACC_FLAT_flag set: >>> -> the class of this field is loaded before computing the layout >>> of the declaring class >>> A - If the field's class is an object class >>> -> same semantic as in 1 is applied >> >> Yes. >> >>> B - If the field's class is a value class >>> -> writing null to this field results in setting this field >>> to the default value of its value class >> >> We have a choice here: We can also throw NPE on >> such writes. I think we should. There's no legitimate >> need for writing a null value to a flat field, I think. >> >> (But maybe there's a translation strategy, that I'm not >> noticing, that could use this behavior?) >> >>> -> reading the default value of this field (uninitialized) >>> returns the default value of its value class >> >> If you can't write null w/o NPE, then the JVM can >> still use the internal trick of allowing null as a >> sentinel for the default value. >> >>> Case 1 is the object world as we know it today, no changes, no >>> additional runtime checks, values will be handled like objects. >>> Case 2-A is the case where the ACC_FLAT has been mis-used >>> on an object class. >>> Case 2-B is the interesting value type case, and its semantic >>> relies only on the presence of the ACC_FLAT flag, not on the >>> decision of the JVM to flatten the field or not. >> >> Exactly. >> >>> Checks to intercept >>> the null value are easy to implement, all information they need >>> are in the field descriptor and on the execution stack. >> >> I agree. Resolving the CONSTANT_Fieldref to the descriptor >> will determine whether the *field* was declared ACC_FLAT. >> In that case null writes will fail and null reads (if any) can be >> handled in some manner convenient to the JVM. >> >>> Bytecode quickening or JIT compilation will help avoiding the ACC_FLAT >>> test completely for cases 1 and 2-A. >> >> Yes. >> > > ? John From david.holmes at oracle.com Wed Jan 31 13:16:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 31 Jan 2018 23:16:42 +1000 Subject: Testing - please ignore Message-ID: <654fc5d3-e670-f63b-f665-0a49cf148810@oracle.com> Sorry - trying to isolate a mail delivery problem. David From karen.kinnear at oracle.com Wed Jan 31 15:05:52 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 31 Jan 2018 10:05:52 -0500 Subject: hg: valhalla/valhalla: Scanner, parser, semantic analysis and attribution support for value types In-Reply-To: References: <201801300919.w0U9Jtg7018815@aojmv0008.oracle.com> Message-ID: <3E67ECA8-0B9C-4ECA-A2A1-971A13C1AEAC@oracle.com> Srikanth, Thank you for the very helpful detailed feedback. In particular, 2,4,5 are all javac language questions - so I will defer to your proposal. Your team can revisit if they disagree. More questions below > On Jan 31, 2018, at 12:43 AM, Srikanth wrote: > > > Hi Karen, > > Thanks for your comments - There is no need for apologizing and such ! I am not looking for a fully evolved specification and am happy to accommodate any changes you require or address any misunderstandings on my part that you call out :) > > Some of the issues you raise though require further discussion and I am pulling up and enumerating these below: > > (In summary ATM (1) through (6) below look as though they don't call for a change - But I will wait for any contrary opinions. > > I'll study (7) and (8) and follow up suitably.) > > (1) Branch to use: > > I have asked David Simms for clarification, but I based my decision to push to "exp" > on http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003663.html. After hearing from David, I'll take suitable follow up actions (including nothing) > > ---- > > (2) Value types may not declare a super class not even j.l.O: > > Please note: In the commit I pushed, value classes *do* extend j.l.O, it is just that they can't explicitly > declare an extends clause even if that only mentions j.l.O > > This is consistent with > > (a) How in the original valhalla prototype, value types extend java.lang.__Value, but cannot mention > an explicit super type in the extends clause. > > (b) This is also consistent with how all annotation types automatically implement java.lang.annotation.Annotation but are not allowed to specify an implements clause in the annotation type declaration site. > > (c) This is also consistent with how all enum types implicitly automatically extend java.lang.Enum, but > cannot expressly extend it. > > (d) Also consistent with how all interfaces have j.l.O as a super type but this cannot be expressed in > source. > > For these reasons I am inclined to think we should leave this matter as is, but can be convinced if I am found to overlook some points. > > ------------ > > (3) "Values have no instance lock and so may not be synchronized upon" > > Clarification: > > (a) A value type may not declare an instance method that has the modifier synchronized AND > (b) A value instance may not be used to furnish the mutual exclusion lock for a synchronized statement. > > (Already done in the prototype) > > ----- > > (4) Values have no identity and consequently the method java.lang.System.identityHashCode may not be invoked on them: > > You wrote: > > I had assumed that java.lang.System.identityHashCode() would be revised to throw an exception at runtime for values, not that javac would catch this > > Certainly a runtime check and throw would be required at j.l.S.identityHashCode(), but it would feel very "unlike Java" to NOT catch this error statically where possible. I agree not all cases could be caught at compile time and so a second line defense would be required at runtime. > > ------ > > (5) The following methods from j.l.O are not allowed on value receivers: clone(), finalize(), wait(), wait(long), wait(long, int), notify, notifyAll > > You wrote: > > Actually they all are - we will be rewriting the j.l.O methods to throw runtime errors if this happens, > so we do not need javac to disallow this > (we will run into this at runtime due to inheritance when passing an Object or interface and the > receiver is a value instance - so we have to do a runtime check anyway) > > I understand how values may "leak" into places where they cannot be discerned to be values statically and hence the rationale for doing a runtime check anyway and rewriting j.l.O methods to throw runtime errors when the receiver happens to be a value instance - but not diagnosing this where it is possible to do so statically in javac would again similar to (4) above be very unlike Java - That is to defer errors to runtime where they can be caught and reported right away at compile time. > > (6) Clarification: I expect Javac would issue a withfield instruction only from the static value factory associated with the value type and nowhere else. As a matter of fact attempt to assign to an instance field of a value type anywhere else would trigger a compile time error about final field being modified, Can you help me with this one - I do not have a good sense of where withfield would make sense to be used be represented in the language. Sounds like you would propose #1 below: 1) explicit value factory, e.g. methods marked in source/in a classfile - for VVT I believe you used __MakeDefault - your sentence above says ?static value factory? - I recognize that for bootstrapping you have to have at least one static value factory - would it also make sense for an instance method that sets a field to create a new value instance using the current values of the starting instance fields and explicitly set a field (or set of fields) 2) in any methods in the current class - for VVT I believe this is what the JVM implemented 3) also for nestmates - TBD Totally makes sense to me that javac would throw compile time errors > > ------ > > (7) Null assignment to values, casting null to values and null comparison against values: > > Thanks for your comments and the pointer to recent discussion. I'll study these in detail and make suitable changes or follow up with requests for additional clarifications. We will be discussing this latest proposal today at both the Valhalla vm meeting and at the expert group, so we should get initial feedback. I will be typing in the EG minutes. > > --- > > (8) Value instances may not be compared with == or != > > You wrote: > > The proposal was that value instances MAY be compared with if_acmpeq/if_acmp_ne, > and the bytecode will return FALSE if either argument is a value type > This presupposes a model in which ?most? code uses a check of ==/!=, null check, .equals() check > > Is this true for source code where it can be discerned by the compiler that one or both of the operands of == or != is a value type ??? > > http://cr.openjdk.java.net/~jrose/values/values-0.html does foresee different semantics for == and != on values, including component-wise == comparison or invoking equals method, but I am not sure where we stand. That is a very old proposal. John spoke with Guy Steele in Burlington in November and came away with his current proposal. See: http://cr.openjdk.java.net/~dlsmith/values-notes.html Dan?s write-up starts with variations in the RLQU world ? the section on Operations is where the LWorld potential option evolved to in November: if_acmpeq and if_acmpne always return false and true, respectively, when invoked on a Q valu See John?s longer email on optimizing acmp below - based on the assumption above: extract: Background: The acmp operation, also known as reference comparison, is overloaded in L-World to handle values as well, with a specific semantics of returning false if either operand is a value (similar to NaN behavior for fcmp). The rationale for this is that acmp is reference comparison, even in L-World, and since values have no references, they can never be equal as references. That does leave us with the question of what javac should do. Would it make sense to issue a warning if javac knows that one or both operands is a value type if there is an ?==? or ?!=? not coupled with a .equals check (and possibly a null check)? Would it make sense to do that even for reference types since any Object or interface could at runtime be a value type? Brian says we have been ?encouraging? folks to do this for 20 years - I don?t know how we teach evolution in java - with a flag? with a warning? That is a language designers call - I added it to our open issues - love it if you work it out with your team and let us jvm folks know the answer :-) thanks, Karen > > Thanks! > Srikanth > > > > On Tuesday 30 January 2018 10:58 PM, Karen Kinnear wrote: >> Srikanth, >> I have not yet had a time to look through the code, but I wanted to get back to you right away. >> >> First - many many thanks for doing this so quickly and for asking for feedback at this >> early phase. >> >> Some clarifications to the list below. My apologies if I incorrectly specified some to you. >> Thank you for your understanding A we have been evolving some key issues such as how to >> deal with signatures and nullability. So this is a good time to touch base. >> >> Also - can you touch base with Mr Simms on the repos - my understanding was that >> the ?exp? branch was for independent performance experiments based on JDK 11 >> without value types support, and he was going to create a new branch ?name TBD? for our joint >> prototype. >> >>> On Jan 30, 2018, at 4:21 AM, Srikanth wrote: >>> >>> >>> Hello, >>> >>> The commit below is the record of the change set I pushed to valhalla "exp" branch >>> that contains the javac changes for scanner, parser, semantic analysis and attribution >>> support for value types. Most of this is leveraged from the existing prototype >>> and tweaked for the present work. >>> >>> No code generation support exists at the moment. I will look into it now. >>> See below for the summary of changes and a couple of questions. >>> >>> Summary of changes: >>> >>> - Tag a type declaration as being a value type with __ByValue modifier (>= JDK11) >> yes >>> - Value types may not declare a super class not even j.l.O >> current proposal is that a value type must explicitly declare j.l.O as the super class >>> - Value class declarations and their instance fields must be final. >> yes >>> - Value types may not declare fields of their own types either directly or indirectly. >> yes >>> - Null cannot be assigned to value types >> This is a very new proposal - still in discussion >> >> http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003721.html >> >> Proposal is to add in the classfile the ACC_NON_NULLABLE flag for FieldInfo >> ? I do not know what the language support should be for a prototype? >> ? keyword? annotation? Needs a langtools team discussion, perhaps >> before that all gets sorted out stick with the keywords like the rest of the prototype, >> e.g. __NonNullable >> >> If the field is declared with the ACC_NON_NULLABLE, then writing to this field >> at runtime with throw and NPE. >> Given that it is illegal to use this flag for an object class (vs. a value class) >> javac could catch both the use of this class for an object class, and catch >> assigning these fields to null. >> >> Let us know if you see a problem with this approach for prototyping >> >>> - Null cannot be casted to or compared with value types. >> Changed: null can be cast to a value type or compared with a value type >> (we left the semantics of checkcast and instanceof unchanged) >> (see below for comparison discussion) >> >>> - Support for static value factories and value instance creation via __MakeDefault() >>> - Values have no instance lock and so may not be synchronized upon. >> clarify: it is illegal to declare a non-static synchronized method for a value class >> >>> - Values have no identity and consequently the method java.lang.System.identityHashCode >>> may not be invoked on them and >> I had assumed that java.lang.System.identityHashCode() would be revised to throw an exception at runtime for values, not that javac would catch this >>> - The following methods from j.l.O are not allowed on value receivers: >>> - clone() >>> - finalize() >>> - wait() >>> - wait(long), >>> - wait(long, int) >>> - notify >>> - notifyAll >> Actually they all are - we will be rewriting the j.l.O methods to throw runtime errors if this happens, >> so we do not need javac to disallow this >> (we will run into this at runtime due to inheritance when passing an Object or interface and the >> receiver is a value instance - so we have to do a runtime check anyway) >>> - Value instances may not be compared with == or != >> The proposal was that value instances MAY be compared with if_acmpeq/if_acmp_ne, >> and the bytecode will return FALSE if either argument is a value type >> This presupposes a model in which ?most? code uses a check of ==/!=, null check, .equals() check >> >>> - Tests for the above restrictions. >>> >>> Questions: >>> >>> 1. ATM, javac forbids comparison of values using != or ==. This behavior is simply >>> brought forward from the original valhalla implementation. Is this what we want in >>> the present prototype ? (in the context of acmp performance characterization ?) >>> 2. The support in the parser allows inner class to be declared as __ByValue. Do we want >>> to restrict values to top level classes ? I seem to recall this being suggested a while >>> ago - but I am unable to dig up the context. >> I added this to the list of open design questions - I think that is a language choice, I don?t >> know why the JVM would care since today it knows nothing really about top level vs >> inner classes. >> Also brings up the question of withfield (renamed) and where it is legal to call it - >> explicit factories, any method in the value class itself, nestmates? >> >> thanks so much, >> Karen >> >> >>> Thanks! >>> Srikanth >>> >>> >>> On Tuesday 30 January 2018 02:49 PM, srikanth.adayapalam at oracle.com wrote: >>>> Changeset: 8d76e47a91e7 >>>> Author: sadayapalam >>>> Date: 2018-01-30 14:45 +0530 >>>> URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8d76e47a91e7 >>>> >>>> Scanner, parser, semantic analysis and attribution support for value types >>>> >>>> ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java >>>> ! src/jdk.compiler/share/classes/com/sun/source/tree/NewClassTree.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >>>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java >>>> ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java >>>> ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java >>>> ! test/langtools/tools/javac/diags/examples.not-yet.txt >>>> + test/langtools/tools/javac/diags/examples/ValuesNotSupported.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckClone.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckEquals.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckFinalize.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckIdentityHash01.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullAssign.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckNullCastable.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckStaticValueFactory.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSuperCompileOnly.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSync.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckSynchronized.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueFactoryWithReference.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.java >>>> + test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.out >>>> + test/langtools/tools/javac/valhalla/lworld-values/Point.java >>>> >> > From karen.kinnear at oracle.com Wed Jan 31 15:26:10 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 31 Jan 2018 10:26:10 -0500 Subject: optimizing acmp in L-World In-Reply-To: <47625659-9B0E-481C-B755-4C5C4E2DE23C@oracle.com> References: <47625659-9B0E-481C-B755-4C5C4E2DE23C@oracle.com> Message-ID: <529B6B1B-603E-4E8C-BD5D-DB4D77F82380@oracle.com> John, Really glad to see the potential performance paths here. A note - the way I understand this, not only does clever_life depend on .Equals() that would never return false for exact pointer matches, new_acmp has the same assumption. I have been assuming that value classes would be able to override Object.equals() (the ?new? implementation of Object.equals() that handles value types with component-wise comparisons). Should we add a requirement that Equals can not ever return false for exact pointer matches? Do we assume that most value types will be able to take advantage of an intrinsic for the new Object.equals()? thanks, Karen > On Jan 29, 2018, at 3:42 PM, John Rose wrote: > > Tobias, Roland, and I had a chat in Santa Clara last week > about optimizing the acmp operation in the JVM. Here are > my notes on it. > > Background: The acmp operation, also known as reference > comparison, is overloaded in L-World to handle values as well, > with a specific semantics of returning false if either operand is > a value (similar to NaN behavior for fcmp). The rationale for > this is that acmp is reference comparison, even in L-World, > and since values have no references, they can never be > equal as references. > > (Alternatively, it is *as if* both operands were converted > *to references* before the acmp operation, which means > that either operand, if it is a value, *would be* boxed to a > reference value, which then, being a new reference, is > automatically unequal to any other reference. This tricky > account may be appealing in some circumstances.) > > OK, so how do we make it fast? Ideally, we would like > to strength-reduce the enhanced acmp instruction down > to the original acmp instruction, which after all is just a > single instruction (such as cmpq) on all platforms. > > The first thing to notice, before going into details, is > that in L-world all Q-values are buffered in the interpreter. > This means that, at least for interpreter-generated values, > all values can be treated as physical pointers, even > if they are logically Q-values. > > (Crib sheet: In L-world, all kinds of values except primitives > are formally carried by L-values, under L-descriptors. True > references can be referred to as R-values of R-type, reference > type, or object class. New value types are referred to as Q-values > of Q-type, value type, or value class. When you don't know what > you have, you can say it's a U-type, which just like a Q-type or > R-type is carried by an L-value under an L-descriptor.) > > This means that the old acmp semantics are almost correct, > in many cases. If you have two L-values and do a pointer > comparison on their physical pointers, and if the pointers > differ, you are done. If the physical pointers compare equal, > then there is one more thing you have to do: Make sure that > the L-value carried by both physical pointers is in fact a > reference, an R-value. > > So the logic looks like this, and the new semantics are in > the second "if" statement: > > bool new_acmp(ptr x, ptr y) { > if (!old_acmp(x, y)) return false; // x != y => false > if (is_value_ptr(x)) return false; // x.is_value => false > return true; > } > bool old_acmp(ptr x, ptr y) { > return x == y; // cmpq etc. > } > > Note that since acmp is symmetric, the JVM has the option > to silently test either x or y for "is_value_ptr" if the two physical > pointers compare equal. > > This leads immediately to the first set of optimizations, which > probably are enough to get us where we want to go. (There > is a second set we can add later.) All the JVM has to do is > prove or detect that one or the other physical pointer either > *is certainly* a Q-value, or *is certainly not* a Q-value. > > If either physical pointer is certainly a Q-value, then the > new_acmp instruction is a constant false. If either physical > pointer is certainly not a Q-value, then the new_acmp > instruction strength reduces to the old_acmp instruction. > > The strength reduction to false can be done in any place > where the type of either operand is known to be a Q-type. > The interpreter doesn't track types, and the acmp instruction > isn't resolved so it can't be quickened to a type context, > but the JIT has lots of type information. Thus, if either > operand of acmp is statically known (or accurately speculated) > to be a value type, then the acmp instruction constant folds > to false. > > Likewise, if either operand is known to be an R-type > (true reference) the acmp may be strength reduced to > a simple reference comparison. This also is likely to > happen in the JIT. It also happens in the interpreter > in the acmp_null instruction, where (obviously) the > second operand is a reference (i.e., null). > > (Note that the type Object is a U-type in L-world, so > Object-to-Object comparisons such as are found in > generic collection code do not benefit from this > optimization. More later on that.) > > The JIT can also track, in its profile, whether various > instructions "see" only Q-values or only R-values. > (The classic HotSpot already tracks "sightings" of > null for similar purposes.) In that case, speculative > narrowings (only Q-types or only R-types) can be > used to short circuit new_acmp down to old_acmp. > > This is useful because the speculation can sometimes > be verified out of a loop body, where the actual acmp > instruction is executed in a loop. Remember that the > JIT can choose which operand of acmp to test for > value-ness; if it chooses a loop invariant, and the > invariant is always Q or always R, then the acmp > inside the loop folds up, no matter what the dynamic > value of the other operand. > > For that matter, even if speculation fails, loop > unswitching can get to a similar result, at the cost > of two copies of the loop. > > So, in many cases, contextual information can allow > the JVM to fold up new_acmp to old_acmp or constant > false. > > In cases such folding fails, there is as simple trick > which can make things easier. Recall that folding > fails when *both* operands are statically U-types, > *neither* operand folding to a Q-type or R-type. > > In that case, the JVM must pick one operand or > the other (it doesn't matter which) and perform > the is_value_ptr operation on it, in such a way > that the result of that operand affects the final > result in the correct way. A naive implementation > of new_acmp adds an extra test-and-branch > to fold in the is_value_ptr test, but a clever might > be able to avoid it. > > Suppose there is a branch free technique for > implementing is_value_ptr, such as extracting > a bit from the physical pointer to the U-value, > or (after a null check) extracting a bit from the > physical pointer of the class metadata pointer > in the value's header, or (after two indirections) > extracting a bit from the structure of the class > metadata. (Mr. Simm's prototype puts such > a bit in the metadata pointer, in the object > header.) > > If such a bit can be obtained in a branch-free > manner, then it can be used to perturb the result > of the old_acmp in a useful manner. For example: > > bool new_acmp(ptr x, ptr y) { > if (x == null) return y == null; > int bit = (x->class_in_header & Q_TYPE_BIT); > ptr x1 = x | swar_broadcast_bit(bit != 0); > return old_acmp(x1, y); > } > int swar_broadcast_bit(bool z) { > return z ? -1 : 0; // use ALU ops > } > > The idea is to extract a bit which signals the presence > of a Q-type (in either operand) and use it to "mess up" > the equality comparison, using and, or, or xor as needed. > > This perturbation technique has two costs: First, > it requires a null check (unless the Q-bit is in the > actual physical reference). Second, it requires > an ALU operation or two to spread the perturbation. > But these costs will probably be negligible, except > (perhaps) in very tight loops in generic code. > > Generic code loops performing frequent acmp operations > on untyped (Object) operands will need to perform > extra null checks and/or value/reference detections > if they are not already present (by luck) in the loop > context. In this case, loop unswitching may be useful. > > There is one more contextual operation which may be > helpful in such cases, if all else fails (and loop unswitching > is not desirable). Honestly, I haven't seen any real-world > code yet that needs it, but it is comforting to have as a > fall-back. The idea is this: If the acmp is contextually > followed by a call to Object.equals, in the usual Legacy > Idiom For Equality (L.I.F.E.), then there is one more trick > we can play. We'd like to force the new_acmp down to > an old_acmp in these cases. Can we? Here's the choice: > > bool dutiful_life(ptr x, ptr y) { > if (new_acmp(x, y)) return true; > return x->Object_equals(y); > } > bool clever_life(ptr x, ptr y) { > if (old_acmp(x, y)) return true; > return x->Object_equals(y); > } > > Note that the only semantic difference between old_acmp > and new_acmp arises when *both* operands are the *same* > value. (Work out the cases: In every other case, the simple > pointer comparison detects the difference and produces the > correct "false" answer.) Thus, in the L.I.F.E., the only case > where old_acmp gives the wrong answer produces an > immediate answer of "true", instead of following up with > a call to x.equals(x) on the Q-value. > > To put it in a nutshell, the only difference between dutiful_life > and clever_life is that the former always calls Object::equals > if either operand is a value, and the the latter calls > Object::equals in a subset of those cases (when the > physical pointers differ). When the physical pointers > do *not* differ, there is no call to Object::equals. But > clever_life always delivers the same answer as dutiful_life. > > So is there a problem? Not much, although it requires us to treat > Object::equals as an intrinsic with some predictable semantics. > The crucial inside that allows us to adopt clever_life is that, > if you call x.equals(x) on a non-null x, the result must always > be true. Now, this is not enforced by the JVM, but it is clearly > documented in the API specification for Object::equals, and > lots of stuff would be already broken if that were ever false. > > Thus, if we are willing to rule out implementations of Object::equals > for which a value can ever compare *not equal* to itself, then > we can substitute clever_life for dutiful_life. We also have to > allow one more thing: That we can silently drop calls to equals > (at least in the context of L.I.F.E.) when the JVM can prove that > the contract of equals allows the JVM to predict the outcome. > This means that if you put side effects (like print statements) > into an equals method on a value type, you might not see the > side effects, after the JVM has optimized things. This corner > case may require further thought in order to straighten it out. > > Note that L.I.F.E. is frequently found in generic code, where > instead of operating on Object values it operates on type > parameter types. (The JVM just sees Object, after erasure.) > In that case, if the JVM were to specialize the generic code > separately for some types (such as value types), along the > lines of the template class proposals, then the L.I.F.E. > code would fold up in the JIT using the rules given at the > top of this note. The generic expression "a == b", where > a or b was a value of a specialized type parameter T, > would fold up to false in every specialization where T was > a Q-type. Likewise, as noted above, if L.I.F.E. is applied > to a true R-type (or specialized to such a type), then any > new_acmp on that type can be short-circuited to the faster > old_acmp. > > All in all, it appears that the cost of the new acmp semantics > can, for all practical purposes, be pushed down into the noise. > > ? John From ben_walsh at uk.ibm.com Wed Jan 31 16:00:52 2018 From: ben_walsh at uk.ibm.com (Ben Walsh) Date: Wed, 31 Jan 2018 16:00:52 +0000 Subject: [PATCH] GPU Exploitation Infrastructure Message-ID: As per the responses to http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/051181.html , I am reposting this patch to this mailing list ... This patch provides the infrastructure to enable the exploitation of a GPU by the compiler to accelerate certain suitable Java constructs. When enabled, a suitable compiler can attempt to accelerate the following Java constructs by launching the corresponding lambda expression on the GPU: IntStream.range().parallel().forEach() IntStream.rangeClosed().parallel().forEach() where: defines upper and lower bounds is a correctly defined lambda expression As it stands, with the HotSpot compiler, this patch performs a "no op" in the newly added in-built native library method. This can be extended so that the HotSpot compiler attempts the acceleration detailed above instead. I would like to pair with a sponsor to contribute this patch ... -------------------------------------------------------------------------------------------------------------- diff -r fd237da7a113 make/hotspot/symbols/symbols-unix --- a/make/hotspot/symbols/symbols-unix Mon Jan 22 23:06:29 2018 -0800 +++ b/make/hotspot/symbols/symbols-unix Tue Jan 30 10:07:18 2018 +0000 @@ -1,5 +1,5 @@ # -# Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -187,3 +187,6 @@ JVM_AddReadsModule JVM_DefineModule JVM_SetBootLoaderUnnamedModule + +# GPU exploitation support +Java_java_util_stream_IntPipeline_promoteGPUCompile diff -r fd237da7a113 src/hotspot/share/include/jvm.h --- a/src/hotspot/share/include/jvm.h Mon Jan 22 23:06:29 2018 -0800 +++ b/src/hotspot/share/include/jvm.h Tue Jan 30 10:07:18 2018 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1189,6 +1189,12 @@ JNIEXPORT jstring JNICALL JVM_GetTemporaryDirectory(JNIEnv *env); +/* + * GPU exploitation support + */ +JNIEXPORT void JNICALL +Java_java_util_stream_IntPipeline_promoteGPUCompile(JNIEnv *env, jobject obj); + /* Generics reflection support. * * Returns information about the given class's EnclosingMethod diff -r fd237da7a113 src/hotspot/share/prims/jvm.cpp --- a/src/hotspot/share/prims/jvm.cpp Mon Jan 22 23:06:29 2018 -0800 +++ b/src/hotspot/share/prims/jvm.cpp Tue Jan 30 10:07:18 2018 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -3661,3 +3661,11 @@ JVM_ENTRY_NO_ENV(jint, JVM_FindSignal(const char *name)) return os::get_signal_number(name); JVM_END + + +// GPU exploitation support stub ///////////////////////////////////////////////////////////////////// + +JVM_ENTRY(void, Java_java_util_stream_IntPipeline_promoteGPUCompile(JNIEnv *env, jobject thisObj)) + JVMWrapper("Java_java_util_stream_IntPipeline_promoteGPUCompile"); + return; +JVM_END diff -r fd237da7a113 src/java.base/share/classes/java/util/stream/AbstractPipeline.java --- a/src/java.base/share/classes/java/util/stream/AbstractPipeline.java Mon Jan 22 23:06:29 2018 -0800 +++ b/src/java.base/share/classes/java/util/stream/AbstractPipeline.java Tue Jan 30 10:07:18 2018 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -373,6 +373,14 @@ return sourceStage.parallel; } + /** + * Returns the sourceSpliterator + * + * @return the sourceSpliterator + */ + final Spliterator getSourceSpliterator() { + return sourceSpliterator; + } /** * Returns the composition of stream flags of the stream source and all diff -r fd237da7a113 src/java.base/share/classes/java/util/stream/IntPipeline.java --- a/src/java.base/share/classes/java/util/stream/IntPipeline.java Mon Jan 22 23:06:29 2018 -0800 +++ b/src/java.base/share/classes/java/util/stream/IntPipeline.java Tue Jan 30 10:07:18 2018 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -433,10 +433,33 @@ } // Terminal ops from IntStream + private static boolean tryGPU = false; + protected static native void promoteGPUCompile(); @Override public void forEach(IntConsumer action) { - evaluate(ForEachOps.makeInt(action, false)); + boolean instanceOfRangeIntSpliterator = getSourceSpliterator() instanceof Streams.RangeIntSpliterator; + if (instanceOfRangeIntSpliterator) { + Streams.RangeIntSpliterator intRange = (Streams.RangeIntSpliterator)getSourceSpliterator(); + int last = intRange.upTo; + if (intRange.upTo != Integer.MAX_VALUE && intRange.last == 1){ + last = intRange.upTo + 1; + } + // tryGPU will be set at runtime using a suitable JVM specific method option + if (tryGPU) { + for (int i = intRange.from; i < last; i++){ + action.accept(i); + } + if (intRange.upTo == Integer.MAX_VALUE && intRange.last == 1){ + action.accept(Integer.MAX_VALUE); + } + return; + } + } + evaluate(ForEachOps.makeInt(action, false)); + if (instanceOfRangeIntSpliterator){ + promoteGPUCompile(); + } } @Override diff -r fd237da7a113 src/java.base/share/classes/java/util/stream/Streams.java --- a/src/java.base/share/classes/java/util/stream/Streams.java Mon Jan 22 23:06:29 2018 -0800 +++ b/src/java.base/share/classes/java/util/stream/Streams.java Tue Jan 30 10:07:18 2018 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -55,12 +55,12 @@ // Can never be greater that upTo, this avoids overflow if upper bound // is Integer.MAX_VALUE // All elements are traversed if from == upTo & last == 0 - private int from; - private final int upTo; + int from; + final int upTo; // 1 if the range is closed and the last element has not been traversed // Otherwise, 0 if the range is open, or is a closed range and all // elements have been traversed - private int last; + int last; RangeIntSpliterator(int from, int upTo, boolean closed) { this(from, upTo, closed ? 1 : 0); -------------------------------------------------------------------------------------------------------------- Regards, Ben Walsh Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From frederic.parain at oracle.com Wed Jan 31 19:08:24 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 31 Jan 2018 14:08:24 -0500 Subject: Moving from VVT to the L-world value types (LWVT) In-Reply-To: <1756463780.140684.1517396079851.JavaMail.zimbra@u-pem.fr> References: <6196218A-A0BD-48EA-BFC9-8B3FD3D5EFB1@oracle.com> <9C55E1B0-2040-4F90-B26A-5FF34676477F@oracle.com> <41A42E5F-B12E-4BA8-93EE-906B621F53F1@oracle.com> <936BD7B3-9E97-4F06-B936-BB5F2A72BA5F@oracle.com> <0BDFD3E5-5A69-4F91-8858-A04E0B4DDE28@oracle.com> <3EEE4192-3617-4E1C-8B7A-363176E1D24D@oracle.com> <1756463780.140684.1517396079851.JavaMail.zimbra@u-pem.fr> Message-ID: <644A69E2-8B7C-4633-92BD-FA1B7665AAC4@oracle.com> Here?s an update of the JVMS draft which includes the semantic proposed below. http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-3.pdf Feedback and comments are welcome. Fred > On Jan 31, 2018, at 05:54, Remi Forax wrote: > > > > ----- Mail original ----- >> De: "Frederic Parain" >> ?: "John Rose" >> Cc: "valhalla-dev" >> Envoy?: Lundi 29 Janvier 2018 20:31:56 >> Objet: Re: Moving from VVT to the L-world value types (LWVT) > >> John, >> >> Silently transforming null into the default value in case 2-B was >> just in case it could ease the handling of migrated case. If throwing >> NPE is OK here, it makes the semantic much cleaner. It also solves >> some problems we had while trying to add support for the null >> value in the value class? equals() method. >> >> During a brainstorming session with Karen this morning, we realized >> that case 2-A (ACC_FLAT flag set for an object class) should be in >> fact treated as an error, instead of just ignoring the flag. > > Which means that changing a value type to a reference type is not a backward compatible change, > i'm Ok with that. > >> >> These two modifications makes the semantic mucho simpler and >> cleaner with only two cases: one where null is always valid, and >> one where null is never valid. >> >> So here?s a re-write of the semantic: >> >> Fields have a new access flag called ACC_NON_NULLABLE. >> >> The type of a field with the ACC_NON_NULLABLE flag set must >> be a value class type, otherwise an ICCE is thrown. >> >> 1 - If a field is declared without the ACC_NON_NULLABLE flag set: >> - this field is initialized with the null reference >> - it is valid to write null to this field >> - note: JVMs are unlikely to flatten such field >> >> 2 - If a field is declared with the ACC_NON_NULLABLE flag set: >> - this field is initialized with the default value of this field?s value class >> - writing null to this field causes a NPE >> - JVMs are encouraged to flatten such field >> >> This semantic makes much more sense because being non-nullable >> is a property of the container more than a property of the field?s type. >> >> Fred > > I agree about the semantics, > the name of the flag is wrong, it should be ACC_FLAT_THUS_NON_NULLABLE :) > > R?mi > >> >>> On Jan 25, 2018, at 17:48, John Rose wrote: >>> >>> On Jan 25, 2018, at 1:51 PM, Frederic Parain wrote: >>>> >>>> Simply allowing non-flattened field to be null is not a viable >>>> solution because a consequence would be that the result of >>>> reading a non-initialized field would depend on wether or not >>>> the field has been flattened. >>> >>> As you note below, it is possible to make the details >>> of null processing depend on whether the *field* was >>> declared flat or not. >>> >>>> With Valhalla Value Types, we were able to use the null >>>> value internally for non-initialized non-flattened field because >>>> the JVM always knew if a field were a value type or not. >>> >>> Nice trick. >>> >>>> Unfortunately, this cannot be done in the L-world because >>>> when a non-initialized field is read, there?s no guarantee that >>>> the class of this field has been loaded yet. >>>> >>>> So, here?s a proposal that provides a semantic for null value >>>> fields that do not depend on the implementation, and without >>>> additional runtime checks for non-value fields: >>>> >>>> 1 - If a field is declared without the ACC_FLAT flag set: >>>> -> it is never flattened (even if the class is already loaded >>>> and it is a value class) >>>> -> it is OK to write null on this field >>>> -> reading the default value of this field returns null >>> >>> Yes, that's what I had in mind too. >>> >>>> 2 - If a field is declared wit the ACC_FLAT_flag set: >>>> -> the class of this field is loaded before computing the layout >>>> of the declaring class >>>> A - If the field's class is an object class >>>> -> same semantic as in 1 is applied >>> >>> Yes. >>> >>>> B - If the field's class is a value class >>>> -> writing null to this field results in setting this field >>>> to the default value of its value class >>> >>> We have a choice here: We can also throw NPE on >>> such writes. I think we should. There's no legitimate >>> need for writing a null value to a flat field, I think. >>> >>> (But maybe there's a translation strategy, that I'm not >>> noticing, that could use this behavior?) >>> >>>> -> reading the default value of this field (uninitialized) >>>> returns the default value of its value class >>> >>> If you can't write null w/o NPE, then the JVM can >>> still use the internal trick of allowing null as a >>> sentinel for the default value. >>> >>>> Case 1 is the object world as we know it today, no changes, no >>>> additional runtime checks, values will be handled like objects. >>>> Case 2-A is the case where the ACC_FLAT has been mis-used >>>> on an object class. >>>> Case 2-B is the interesting value type case, and its semantic >>>> relies only on the presence of the ACC_FLAT flag, not on the >>>> decision of the JVM to flatten the field or not. >>> >>> Exactly. >>> >>>> Checks to intercept >>>> the null value are easy to implement, all information they need >>>> are in the field descriptor and on the execution stack. >>> >>> I agree. Resolving the CONSTANT_Fieldref to the descriptor >>> will determine whether the *field* was declared ACC_FLAT. >>> In that case null writes will fail and null reads (if any) can be >>> handled in some manner convenient to the JVM. >>> >>>> Bytecode quickening or JIT compilation will help avoiding the ACC_FLAT >>>> test completely for cases 1 and 2-A. >>> >>> Yes. >>> >>> ? John From mandy.chung at oracle.com Wed Jan 31 19:13:56 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 31 Jan 2018 11:13:56 -0800 Subject: [Nestmates] RFR: 8196320: [Nestmates] Restore the old enclosing-class based isSamePackageMember check in sun/invoke/util/VerifyAccess.java In-Reply-To: <7880cf5b-8f17-cc43-ce91-1285bcaaac8b@oracle.com> References: <7880cf5b-8f17-cc43-ce91-1285bcaaac8b@oracle.com> Message-ID: On 1/30/18 8:54 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8196320 > webrev: http://cr.openjdk.java.net/~dholmes/8196320/webrev/ > > I've restored the original enclosing-class check and the > isSamePackageMember method, but renamed it to areNestMates. It will > first do the real Reflection.areNestMates check, and if that fails > fall-back to the pre-nestmate enclosing class check. > Does core reflection work with the pre-nestmate class scenario? Should JVM_AreNestMates handle the pre-nestmate class and return true if they are the same class or same runtime package? > I've added a test under runtime/Nestmates/legacy (where I'll > accumulate tests that check legacy code still works after the nestmate > changes - for specific areas like this.) At some point we should look at where the nestmates tests should be placed.? For example, this test seems to be appropriate to land in test/jdk/java/lang/invoke.?? Just a note to consider when integrating this to jdk. > The test will need tweaking once we bump the version to 11 > (unfortunately there's no system property that reports the classfile > version AFAICS). Are you referring to this check: 39 static boolean VMHasNestmates = 40 System.getProperty("java.vm.specification.version").equals("10"); : 84 if (!VMHasNestmates) { 85 throw new Error("This test is only for JDK 11 with nestmates"); 86 } If so, I don't think you need this check. This test uses Class::getNestHost method that will fail to compile if running on an older JDK. Nit: 30 * @compile -source 10 -target 10 TestPrivateLookup.java Alternatively it can use --release 10 instead of -source and -target. Mandy