From lesliezhai at llvm.org.cn Sun Apr 1 01:05:12 2018 From: lesliezhai at llvm.org.cn (Leslie Zhai) Date: Sun, 1 Apr 2018 09:05:12 +0800 Subject: [aarch64-port-dev ] How to migrate hs17's LIR_Assembler::emit_exception_handler to hs25? In-Reply-To: <1e020d92-3388-71b1-f35b-04a6ed266976@redhat.com> References: <6c76544b-0830-bd5d-d1af-538372b1a269@llvm.org.cn> <1e020d92-3388-71b1-f35b-04a6ed266976@redhat.com> Message-ID: +DA7B79A2EB6F4A23 Hi Andrew, Thanks for your response! ? 2018?04?01? 01:21, Andrew Haley ??: > On 03/27/2018 04:57 PM, Leslie Zhai wrote: >> Hi HotSpot compiler developers, >> >> I am new to HotSpot, and trying to migrate hs17 to hs25, but JDK-6919934 >> changed: > Hi, > > What exactly are you trying to do? Why do you need to do this? > Are you porting this 8 years old HotSpot to another processor? > > If you explained, people might help. I am learning x86 [1] and aarch64 [2] for porting to other *targets*, for example, riscv. I often investigate the history of changeset when porting, for an instance, LLVM instruction selection SelectionDAG porting to GlobalISel [3] And I found that JDK-6964458, JDK-7012914, JDK-6919934 ... refactory heavily, so I need to make a ChangeLog about the migration [4] > >> Then reuse hs17's `LIR_Assembler::emit_exception_handler`, >> `Runtime1::generate_handle_exception`, `Runtime1::generate_code_for`... >> in hs25, but it is monkey patch... not easy to merge upstream. >> >> Please share your porting experience, and give me some advice, thanks a lot! > I didn't write the AArch64 port of that code until 2013, I'm afraid. But > none of the x86 code looks particularly weird: it's just tedious. > I feel awe when porting DraongEgg to GCC 8.x and LLVM 7.x [5] and my sincere thanks will goto your colleague David Malcolm, he taught me a lot about migrating from GCC 4.x to 8.x [1] http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/a74480137e6e/src/cpu/x86/vm [2] http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/file/b08b1e9e2963/src/cpu/aarch64/vm [3] http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html [4] https://www.leetcode.cn/2018/03/migrate-hs14-to-25.html [5] https://gcc.gnu.org/ml/gcc/2017-08/msg00245.html -- Regards, Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/ From yang.zhang at linaro.org Tue Apr 3 02:44:37 2018 From: yang.zhang at linaro.org (Yang Zhang) Date: Tue, 3 Apr 2018 10:44:37 +0800 Subject: [aarch64-port-dev ] RFD: AOT for AArch64 In-Reply-To: References: <83f0e948-d002-6b71-e73f-6f65fce14e3b@redhat.com> <6f669937-6e59-b4e8-e77b-1fe727dfc9e5@bell-sw.com> <53daf9a7-5108-06ce-bb05-6b10612c48d8@bell-sw.com> Message-ID: Hi Andrew Thanks for your great work on aot. I'm also testing your patches on jdk and graal. There are many discussions on your patches. I'm not sure if I miss some updates in the comments. Could you share your latest patches(hs and graal) and jtreg command so that I can test them in my environment again? Regards Yang On 29 March 2018 at 23:46, Andrew Haley wrote: > There's a problem with assertions being fired which is apparently due > to a recent Graal bug. Try running without assertions: > > diff -r ee513596f3ee test/hotspot/jtreg/compiler/aot/AotCompiler.java > --- a/test/hotspot/jtreg/compiler/aot/AotCompiler.java Tue Jan 30 16:41:40 2018 +0100 > +++ b/test/hotspot/jtreg/compiler/aot/AotCompiler.java Thu Mar 29 16:37:21 2018 +0100 > @@ -114,8 +114,8 @@ > args.add(linker); > } > // Execute with asserts > - args.add("-J-ea"); > - args.add("-J-esa"); > + // args.add("-J-ea"); > + // args.add("-J-esa"); > return launchJaotc(args, extraopts); > } > > With that change, I get two failures. If you're seeing a lot more > failures than that, please look t your test configuration. > > Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2AotTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2CompiledTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2NativeTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2InterpretedTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeInterface2InterpretedTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeInterface2CompiledTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeInterface2NativeTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2AotTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2NativeTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2CompiledTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2InterpretedTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeStatic2AotTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeStatic2InterpretedTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeStatic2NativeTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeStatic2CompiledTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2AotTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2CompiledTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2InterpretedTest.java > Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2NativeTest.java > Passed: compiler/aot/calls/fromCompiled/CompiledInvokeDynamic2AotTest.java > Passed: compiler/aot/calls/fromCompiled/CompiledInvokeInterface2AotTest.java > Passed: compiler/aot/calls/fromCompiled/CompiledInvokeSpecial2AotTest.java > Passed: compiler/aot/calls/fromCompiled/CompiledInvokeStatic2AotTest.java > Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeInterface2AotTest.java > Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeSpecial2AotTest.java > Passed: compiler/aot/calls/fromCompiled/CompiledInvokeVirtual2AotTest.java > Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeDynamic2AotTest.java > Passed: compiler/aot/calls/fromNative/NativeInvokeStatic2AotTest.java > Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeStatic2AotTest.java > Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeVirtual2AotTest.java > Passed: compiler/aot/calls/fromNative/NativeInvokeSpecial2AotTest.java > Passed: compiler/aot/cli/jaotc/ClasspathOptionUnknownClassTest.java > Passed: compiler/aot/cli/jaotc/CompileClassTest.java > Passed: compiler/aot/calls/fromNative/NativeInvokeVirtual2AotTest.java > Passed: compiler/aot/cli/jaotc/CompileClassWithDebugTest.java > Passed: compiler/aot/cli/jaotc/CompileDirectoryTest.java > Passed: compiler/aot/cli/jaotc/CompileModuleTest.java > Passed: compiler/aot/cli/jaotc/CompileJarTest.java > Passed: compiler/aot/cli/jaotc/ListOptionNotExistingTest.java > Passed: compiler/aot/cli/jaotc/ListOptionTest.java > Passed: compiler/aot/cli/jaotc/ListOptionWrongFileTest.java > Passed: compiler/aot/cli/DisabledAOTWithLibraryTest.java > Passed: compiler/aot/cli/IncorrectAOTLibraryTest.java > Passed: compiler/aot/cli/NonExistingAOTLibraryTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/directory/DirectorySourceProviderTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/jar/JarSourceProviderTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/module/ModuleSourceProviderTest.java > Passed: compiler/aot/cli/SingleAOTLibraryTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/ClassSearchTest.java > Passed: compiler/aot/cli/MultipleAOTLibraryTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/ClassSourceTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/SearchPathTest.java > Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/NativeOrderOutputStreamTest.java > Passed: compiler/aot/verification/vmflags/NotTrackedFlagTest.java > Passed: compiler/aot/cli/SingleAOTOptionTest.java > Passed: compiler/aot/verification/vmflags/TrackedFlagTest.java > Passed: compiler/aot/verification/ClassAndLibraryNotMatchTest.java > Passed: compiler/aot/SharedUsageTest.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Method is unexpectedly compiled after deoptimization: expected false, was true > -------------------------------------------------- > Passed: compiler/aot/RecompilationTest.java > Test results: passed: 60; failed: 1 > Report written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_aot/html/report.html > Results written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_aot > Error: Some tests failed or other problems occurred. > Finished running test 'jtreg:test/hotspot/jtreg/compiler/aot' > Test report is stored in build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_aot > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg/compiler/aot 61 60 1 0 << > ============================== > TEST FAILURE > > * jtreg:test/hotspot/jtreg/compiler/jvmci > > Running test 'jtreg:test/hotspot/jtreg/compiler/jvmci' > Passed: compiler/jvmci/compilerToVM/AsResolvedJavaMethodTest.java > Passed: compiler/jvmci/compilerToVM/CollectCountersTest.java > Passed: compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java > -------------------------------------------------- > ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: CompileCodeTestCase{executable=public default int compiler.jvmci.compilerToVM.CompileCodeTestCase$Interface.defaultMethod(java.lang.Object), bci=-1} : 2nd invocation returned different value: expected > -------------------------------------------------- > Passed: compiler/jvmci/compilerToVM/AllocateCompileIdTest.java > Passed: compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java > Passed: compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java > Passed: compiler/jvmci/compilerToVM/DebugOutputTest.java > Passed: compiler/jvmci/compilerToVM/GetBytecodeTest.java > Passed: compiler/jvmci/compilerToVM/GetClassInitializerTest.java > Passed: compiler/jvmci/compilerToVM/GetConstantPoolTest.java > Passed: compiler/jvmci/compilerToVM/GetExceptionTableTest.java > Passed: compiler/jvmci/compilerToVM/GetImplementorTest.java > Passed: compiler/jvmci/compilerToVM/GetLineNumberTableTest.java > Passed: compiler/jvmci/compilerToVM/GetFlagValueTest.java > Passed: compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java > Passed: compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java > Passed: compiler/jvmci/compilerToVM/GetNextStackFrameTest.java > Passed: compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java > Passed: compiler/jvmci/compilerToVM/GetStackTraceElementTest.java > Passed: compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java > Passed: compiler/jvmci/compilerToVM/GetSymbolTest.java > Passed: compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java > Passed: compiler/jvmci/compilerToVM/HasNeverInlineDirectiveTest.java > Passed: compiler/jvmci/compilerToVM/IsCompilableTest.java > Passed: compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java > Passed: compiler/jvmci/compilerToVM/IsMatureTest.java > Passed: compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java > Passed: compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java > Passed: compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java > Passed: compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java > Passed: compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java > Passed: compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java > Passed: compiler/jvmci/compilerToVM/LookupNameInPoolTest.java > Passed: compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java > Passed: compiler/jvmci/compilerToVM/LookupTypeTest.java > Passed: compiler/jvmci/compilerToVM/ReadConfigurationTest.java > Passed: compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java > Passed: compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java > Passed: compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java > Passed: compiler/jvmci/compilerToVM/ResolveMethodTest.java > Passed: compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java > Passed: compiler/jvmci/compilerToVM/ReprofileTest.java > Passed: compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java > Passed: compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java > Passed: compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java > Passed: compiler/jvmci/errors/TestInvalidCompilationResult.java > Passed: compiler/jvmci/errors/TestInvalidDebugInfo.java > Passed: compiler/jvmci/errors/TestInvalidOopMap.java > Passed: compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java > Passed: compiler/jvmci/events/JvmciShutdownEventTest.java > Passed: compiler/jvmci/events/JvmciNotifyInstallEventTest.java > Passed: compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/HotSpotConstantReflectionProviderTest.java > Passed: compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java > Passed: compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java > Passed: compiler/jvmci/meta/StableFieldTest.java > Passed: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java > Passed: compiler/jvmci/TestJVMCIPrintProperties.java > Passed: compiler/jvmci/JVM_GetJVMCIRuntimeTest.java > Passed: compiler/jvmci/TestValidateModules.java > Passed: compiler/jvmci/SecurityRestrictionsTest.java > Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java > Test results: passed: 72; failed: 1 > Report written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_jvmci/html/report.html > Results written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_jvmci > Error: Some tests failed or other problems occurred. > Finished running test 'jtreg:test/hotspot/jtreg/compiler/jvmci' > Test report is stored in build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_jvmci > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg/compiler/jvmci 73 72 1 0 << > ============================== > TEST FAILURE From aph at redhat.com Tue Apr 3 17:28:40 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Apr 2018 18:28:40 +0100 Subject: [aarch64-port-dev ] AOT for AArch64: current status In-Reply-To: References: <83f0e948-d002-6b71-e73f-6f65fce14e3b@redhat.com> <15f51315-3497-6c01-2ecb-1f758762e99e@redhat.com> <849a8fcf-85cd-b8c6-1134-9aea3877e9b7@redhat.com> <2c42186a-523e-6912-6eb0-36c7ee2be09f@redhat.com> <8b4a211e-44af-ed28-5abf-697d722771d1@redhat.com> <97d96f0e-43b0-beca-3b31-3dabc6073f3a@redhat.com> <8342caa0-e4d1-0250-02ab-c8f9cf8085bd@redhat.com> Message-ID: <6ed685f0-c851-d12f-1788-a896f4e0d162@redhat.com> I fixed a bug in Graal which was causing compiler.aot.DeoptimizationTest to fail. I fixed the bug which was causing assertion failures due to branch out of range. I pulled from the tip of Graal master. It should all be up to date now. All pushed to https://github.com/theRealAph/graal.git aarch64-branch-overflows I'm still seeing some assertion failures, but they're not in my code and I don't think they're anything to do with me. They all seem to do with types not being registered. Updating Graal didn't help, so I need to try to figure out why this isn't a problem on x86. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Apr 5 15:34:17 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 5 Apr 2018 18:34:17 +0300 Subject: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm instruction encoding hits assert on zero register Message-ID: Hi, please review small fix for? 8201185 - AARCH64: bfm instruction encoding hits assert on zero register bfm* instuctions encoding hits assert when using zero register as source, which should be allowed. Fix is trivial: change "general register encoding" call (rf) to "zero-or-general register encoding" call (zrf). CR: https://bugs.openjdk.java.net/browse/JDK-8201185 webrev: http://cr.openjdk.java.net/~dpochepk/8201185/webrev.01/ I've checked this patch (and actually found this bug) by creating intrinsic with such encoding usage. Thanks, Dmitrij From aph at redhat.com Thu Apr 5 15:38:53 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 5 Apr 2018 16:38:53 +0100 Subject: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm instruction encoding hits assert on zero register In-Reply-To: References: Message-ID: <93d47fa2-71ed-1098-92cb-edc0899c3c09@redhat.com> On 04/05/2018 04:34 PM, Dmitrij Pochepko wrote: > please review small fix for? 8201185 - AARCH64: bfm instruction encoding > hits assert on zero register > > bfm* instuctions encoding hits assert when using zero register as > source, which should be allowed. > > Fix is trivial: change "general register encoding" call (rf) to > "zero-or-general register encoding" call (zrf). > > > CR: https://bugs.openjdk.java.net/browse/JDK-8201185 > > webrev: http://cr.openjdk.java.net/~dpochepk/8201185/webrev.01/ > > > I've checked this patch (and actually found this bug) by creating > intrinsic with such encoding usage. Ooh, clever. I never thought anyone would to that. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Apr 5 16:08:20 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 5 Apr 2018 19:08:20 +0300 Subject: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm instruction encoding hits assert on zero register In-Reply-To: <93d47fa2-71ed-1098-92cb-edc0899c3c09@redhat.com> References: <93d47fa2-71ed-1098-92cb-edc0899c3c09@redhat.com> Message-ID: <954bf982-591c-5351-257d-3588097ca462@bell-sw.com> Thank you for review. On 05.04.2018 18:38, Andrew Haley wrote: > On 04/05/2018 04:34 PM, Dmitrij Pochepko wrote: >> please review small fix for? 8201185 - AARCH64: bfm instruction encoding >> hits assert on zero register >> >> bfm* instuctions encoding hits assert when using zero register as >> source, which should be allowed. >> >> Fix is trivial: change "general register encoding" call (rf) to >> "zero-or-general register encoding" call (zrf). >> >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8201185 >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8201185/webrev.01/ >> >> >> I've checked this patch (and actually found this bug) by creating >> intrinsic with such encoding usage. > Ooh, clever. I never thought anyone would to that. OK. > From Derek.White at cavium.com Thu Apr 5 17:02:40 2018 From: Derek.White at cavium.com (White, Derek) Date: Thu, 5 Apr 2018 17:02:40 +0000 Subject: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm instruction encoding hits assert on zero register In-Reply-To: <954bf982-591c-5351-257d-3588097ca462@bell-sw.com> References: <93d47fa2-71ed-1098-92cb-edc0899c3c09@redhat.com> <954bf982-591c-5351-257d-3588097ca462@bell-sw.com> Message-ID: Hi Dmitrij, Looks good. Does this allow the equivalent of BFC instruction (Bitfield Clear)? - Derek > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > Sent: Thursday, April 05, 2018 12:08 PM > To: Andrew Haley ; hotspot-compiler- > dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm > instruction encoding hits assert on zero register > > Thank you for review. > > > On 05.04.2018 18:38, Andrew Haley wrote: > > On 04/05/2018 04:34 PM, Dmitrij Pochepko wrote: > >> please review small fix for? 8201185 - AARCH64: bfm instruction > >> encoding hits assert on zero register > >> > >> bfm* instuctions encoding hits assert when using zero register as > >> source, which should be allowed. > >> > >> Fix is trivial: change "general register encoding" call (rf) to > >> "zero-or-general register encoding" call (zrf). > >> > >> > >> CR: https://bugs.openjdk.java.net/browse/JDK-8201185 > >> > >> webrev: http://cr.openjdk.java.net/~dpochepk/8201185/webrev.01/ > >> > >> > >> I've checked this patch (and actually found this bug) by creating > >> intrinsic with such encoding usage. > > Ooh, clever. I never thought anyone would to that. OK. > > From dmitrij.pochepko at bell-sw.com Thu Apr 5 17:20:17 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 5 Apr 2018 20:20:17 +0300 Subject: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm instruction encoding hits assert on zero register In-Reply-To: References: <93d47fa2-71ed-1098-92cb-edc0899c3c09@redhat.com> <954bf982-591c-5351-257d-3588097ca462@bell-sw.com> Message-ID: <95e6ccfc-b907-b576-608a-23e5019f6554@bell-sw.com> Hi, You're noticed right. It is case of bfc, which is alias of bfm in case source register is zr. And now we can use it, since encoding is fixed. Thanks, Dmitrij On 05.04.2018 20:02, White, Derek wrote: > Hi Dmitrij, > > Looks good. Does this allow the equivalent of BFC instruction (Bitfield Clear)? > > - Derek > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko >> Sent: Thursday, April 05, 2018 12:08 PM >> To: Andrew Haley ; hotspot-compiler- >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(XXS): 8201185 - AARCH64: bfm >> instruction encoding hits assert on zero register >> >> Thank you for review. >> >> >> On 05.04.2018 18:38, Andrew Haley wrote: >>> On 04/05/2018 04:34 PM, Dmitrij Pochepko wrote: >>>> please review small fix for? 8201185 - AARCH64: bfm instruction >>>> encoding hits assert on zero register >>>> >>>> bfm* instuctions encoding hits assert when using zero register as >>>> source, which should be allowed. >>>> >>>> Fix is trivial: change "general register encoding" call (rf) to >>>> "zero-or-general register encoding" call (zrf). >>>> >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8201185 >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8201185/webrev.01/ >>>> >>>> >>>> I've checked this patch (and actually found this bug) by creating >>>> intrinsic with such encoding usage. >>> Ooh, clever. I never thought anyone would to that. OK. >>> From Derek.White at cavium.com Thu Apr 5 18:54:09 2018 From: Derek.White at cavium.com (White, Derek) Date: Thu, 5 Apr 2018 18:54:09 +0000 Subject: [aarch64-port-dev ] Possible aarch64 bug with RoundFPResults Message-ID: Hi porters, I'm looking over "RFR: 8145665: Make UseSSE an x86 specific option and cleanup its usage in shared code", and saw an odd thing: AARCH64 defines RoundFPResults=true, like x86 does, not like PPC, arm, s390, etc. This flag controls (along with UseSSE) cases where CPUs need to explicitly round to 64-bit FP. Which we should never have to do on AARCH64? Is this a real issue or am I imagining it? This is becoming more urgent because JDK-8145665 is removing UseSSE from non-x86 code, which would result in more use of rounding. Thanks, * Derek From ci_notify at linaro.org Thu Apr 5 22:47:48 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 5 Apr 2018 22:47:48 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1645487964.4974.1522968469053.JavaMail.jenkins@4a1669f5d0e4> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/095/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/11 pass: 7,585; fail: 729; error: 25 Build 1: aarch64/2018/jan/13 pass: 7,591; fail: 726; error: 22 Build 2: aarch64/2018/jan/19 pass: 7,598; fail: 720; error: 23 Build 3: aarch64/2018/jan/21 pass: 7,595; fail: 717; error: 29 Build 4: aarch64/2018/feb/21 pass: 7,623; fail: 749; error: 27 Build 5: aarch64/2018/mar/15 pass: 7,693; fail: 692; error: 20 Build 6: aarch64/2018/mar/17 pass: 7,654; fail: 727; error: 24 Build 7: aarch64/2018/mar/19 pass: 7,657; fail: 722; error: 26 Build 8: aarch64/2018/mar/21 pass: 7,652; fail: 732; error: 21 Build 9: aarch64/2018/mar/23 pass: 7,629; fail: 752; error: 24 Build 10: aarch64/2018/mar/25 pass: 7,778; fail: 629; error: 20 Build 11: aarch64/2018/mar/27 pass: 7,773; fail: 634; error: 20 Build 12: aarch64/2018/mar/29 pass: 7,790; fail: 617; error: 20 Build 13: aarch64/2018/mar/31 pass: 7,766; fail: 643; error: 18 Build 14: aarch64/2018/apr/05 pass: 7,787; fail: 619; error: 21 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/11 pass: 3,824; fail: 5; error: 1 Build 1: aarch64/2018/jan/13 pass: 3,821; fail: 5; error: 4 Build 2: aarch64/2018/jan/19 pass: 3,825; fail: 5; error: 5 Build 3: aarch64/2018/jan/21 pass: 3,824; fail: 5; error: 6 Build 4: aarch64/2018/feb/21 pass: 3,831; fail: 6; error: 9 Build 5: aarch64/2018/mar/15 pass: 3,842; fail: 6; error: 4 Build 6: aarch64/2018/mar/17 pass: 3,842; fail: 6; error: 4 Build 7: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 8: aarch64/2018/mar/21 pass: 3,844; fail: 6; error: 2 Build 9: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 10: aarch64/2018/mar/25 pass: 3,844; fail: 6; error: 7 Build 11: aarch64/2018/mar/27 pass: 3,847; fail: 6; error: 4 Build 12: aarch64/2018/mar/29 pass: 3,849; fail: 6; error: 2 Build 13: aarch64/2018/mar/31 pass: 3,851; fail: 6 Build 14: aarch64/2018/apr/05 pass: 3,851; fail: 6 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/11 pass: 7,590; fail: 724; error: 25 Build 1: aarch64/2018/jan/13 pass: 7,598; fail: 715; error: 26 Build 2: aarch64/2018/jan/19 pass: 7,620; fail: 700; error: 21 Build 3: aarch64/2018/jan/21 pass: 7,600; fail: 714; error: 27 Build 4: aarch64/2018/feb/21 pass: 7,656; fail: 716; error: 27 Build 5: aarch64/2018/mar/15 pass: 7,680; fail: 703; error: 22 Build 6: aarch64/2018/mar/17 pass: 7,670; fail: 711; error: 24 Build 7: aarch64/2018/mar/19 pass: 7,669; fail: 714; error: 22 Build 8: aarch64/2018/mar/21 pass: 7,675; fail: 711; error: 19 Build 9: aarch64/2018/mar/23 pass: 7,643; fail: 740; error: 22 Build 10: aarch64/2018/mar/25 pass: 7,811; fail: 599; error: 17 Build 11: aarch64/2018/mar/27 pass: 7,794; fail: 614; error: 19 Build 12: aarch64/2018/mar/29 pass: 7,823; fail: 585; error: 19 Build 13: aarch64/2018/mar/31 pass: 7,798; fail: 611; error: 18 Build 14: aarch64/2018/apr/05 pass: 7,816; fail: 593; error: 18 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/11 pass: 3,824; fail: 5; error: 1 Build 1: aarch64/2018/jan/13 pass: 3,819; fail: 5; error: 6 Build 2: aarch64/2018/jan/19 pass: 3,829; fail: 5; error: 1 Build 3: aarch64/2018/jan/21 pass: 3,827; fail: 5; error: 3 Build 4: aarch64/2018/feb/21 pass: 3,838; fail: 6; error: 2 Build 5: aarch64/2018/mar/15 pass: 3,845; fail: 6; error: 1 Build 6: aarch64/2018/mar/17 pass: 3,841; fail: 6; error: 5 Build 7: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 8: aarch64/2018/mar/21 pass: 3,841; fail: 6; error: 5 Build 9: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 10: aarch64/2018/mar/25 pass: 3,850; fail: 6; error: 1 Build 11: aarch64/2018/mar/27 pass: 3,848; fail: 6; error: 3 Build 12: aarch64/2018/mar/29 pass: 3,848; fail: 6; error: 3 Build 13: aarch64/2018/mar/31 pass: 3,850; fail: 6; error: 1 Build 14: aarch64/2018/apr/05 pass: 3,851; fail: 6 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.00x Relative performance: Server critical-jOPS (nc): 0.83x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 67.54, Server: 113.83 Client 67.54 / Client 2014-04-01 (43.00): 1.57x Server 113.83 / Server 2014-04-01 (71.00): 1.60x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2018-01-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/011/results/ 2018-01-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/013/results/ 2018-01-20 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/019/results/ 2018-01-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/021/results/ 2018-02-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/052/results/ 2018-03-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/074/results/ 2018-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/076/results/ 2018-03-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/078/results/ 2018-03-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/080/results/ 2018-03-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/082/results/ 2018-03-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/084/results/ 2018-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/086/results/ 2018-03-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/088/results/ 2018-03-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/090/results/ 2018-04-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/095/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From dms at samersoff.net Fri Apr 6 07:00:06 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Fri, 6 Apr 2018 10:00:06 +0300 Subject: [aarch64-port-dev ] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <02e62700-efaf-918e-f04e-031dd4788aa0@bell-sw.com> Message-ID: Dmitrij, This version looks good to me. -Dmitry\S On 16/03/2018 19:21, Dmitrij Pochepko wrote: > Hi Andrew, all, > > I modified patch according to your comments. > > First, regarding size statistics: I looked into string size statistics > which was measured for JEP254: Compact Strings > (http://docs.huihoo.com/javaone/2015/CON5483-Compact-Strings-A-Memory-Efficient-Internal-Representation-for-Strings.pdf). > Conclusions are that 75% of strings <= 32 symbols, so we can take this > number into account. This also means that changing string equals code to > be capable of prefetching(and thus adding branch for that) is not > practical. Arrays are another story. So, I split array equals and string > equals. > > String equals remains basically unchanged(the only noticeable change is > that I removed size calculations for UTF strings (asr to convert > length-in-bytes into length-in-characters, and than converting it back > via lsr). It save 2 instructions for this code path: about 5% > improvement on small sizes. > > Array equals was completely re-written. > > For array equals I have 2 algorithms, controlled by vm option: > UseSimpleArrayEquals. First algorithm(simple one) is basically the same > as original one with slightly another branch logic. It seems like Cortex > A7* series prefer shorter code, which fits better for speculative > execution. All other CPUs I was able to check(Cortex A53 and Cavium h/w) > prefer algorithm with large loop and possible prefetching. > > Regarding your comment about addresses at the end of memory page: you're > right. It is indeed possible in theory to use this code for some > substring, however, due to the nature of algorithm for array equals(it > reads array length from array header directly and then jump to first > array element), memory access will always be 8-byte aligned, then it's > safe to use 8-byte loads for array tails. So, I believe this issue is > now naturally resolved, since I left string equals logic unchanged. > > > Now, benchmarks: > > I modified benchmark to have better measurements accuracy by increasing > amount of data processed in each iteration > (http://cr.openjdk.java.net/~dpochepk/8187472/ArrayAltEquals.java) and > has following improvement average numbers for array equals: > > Cavium "ThunderX 2": > length 1..8: 10-20% > length 9..16: 1% > length 17..32: 5-10% > large(512+): almost 2 times > > Cavium "Thunder X": > length 1..8: 1% > length 9..16: 2-3% > length 17..32: 5% > large arrays(512+): up to 5 times > > Cortex A53 (R-Pi): > all ranges are about 5% average (note: large results dispersion (about > 10%) on R-PI) > > Cortex A73: > basically no changes because implementation is almost the same (better > by about 0.5% average, but dispersion is about 4%, so it's not a > statistically significant result) > > > More detailed benchmarking results can be found here: > http://cr.openjdk.java.net/~dpochepk/8187472/array_equals_total.xls > > updated webrev: http://cr.openjdk.java.net/~dpochepk/8187472/webrev.08/ > > Testing: passed jtreg hotspot tests on AArch64 fastdebug build. no new > failures found in comparison with non-patched build. > > I also additionally used "brute-force" test which checks all array > equality combinations for any given length ranges: > http://cr.openjdk.java.net/~dpochepk/8187472/ArrayEqTest.java > > > Thanks, > > Dmitrij > > On 08.02.2018 13:11, Andrew Haley wrote: >> On 07/02/18 19:39, Dmitrij Pochepko wrote: >>> In general, this patch changes very short arrays handling(performing >>> 8-byte read instead of few smaller reads, using the fact of 8-byte >>> alignment) and jumping into stub with large 64-byte read loop for larger >>> arrays). >>> >>> Measurements(measured array length 7,64,128,256,512,1024,100000. >>> Improvement in %. 80% improvement means that new version is 80% faster, >>> i.e. 5 times.): >>> >>> >>> ThunderX: 2%, -4%, 0%, 2%, 32%, 55%, 80% >>> >>> ThunderX2: 0%, -3%, 17%, 19%, 29%, 31%, 47% >>> >>> Cortex A53 at 533MHz: 8%, -1%, -2%, 4%, 6%, 5%, 3% >>> >>> Cortex A73 at 903MHz: 8%, -3%, 0%, 7%, 8%, 9%, 8% >>> >>> Note: medium sizes are a bit slower because of additional branch >>> added(which checks size and jumps to stub). >> This indentation is messed up: >> >> @@ -5201,40 +5217,23 @@ >> ??? // length == 4. >> ??? if (log_elem_size > 0) >> ????? lsl(cnt1, cnt1, log_elem_size); >> -? ldr(tmp1, Address(a1, cnt1)); >> -? ldr(tmp2, Address(a2, cnt1)); >> +??? ldr(tmp1, Address(a1, cnt1)); >> +??? ldr(tmp2, Address(a2, cnt1)); >> >> I'm not convinced that this works correctly if passed the address of a >> pair >> of arrays at the end of a page.? Maybe it isn't used on sub-arrays today >> in HotSpot, but one day it might be. >> >> It pessimizes a very common case of strings, those of about 32 >> characters. >> Please think again.? Please also think about strings that are long enough >> for the SIMD loop but differ in their early substrings. >> From aph at redhat.com Fri Apr 6 08:30:19 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 6 Apr 2018 09:30:19 +0100 Subject: [aarch64-port-dev ] Possible aarch64 bug with RoundFPResults In-Reply-To: References: Message-ID: On 04/05/2018 07:54 PM, White, Derek wrote: > I'm looking over "RFR: 8145665: Make UseSSE an x86 specific option and cleanup its usage in shared code", and saw an odd thing: > > AARCH64 defines RoundFPResults=true, like x86 does, not like PPC, arm, s390, etc. > > This flag controls (along with UseSSE) cases where CPUs need to explicitly round to 64-bit FP. Which we should never have to do on AARCH64? > > Is this a real issue or am I imagining it? > > This is becoming more urgent because JDK-8145665 is removing UseSSE from non-x86 code, which would result in more use of rounding. It's only used by C1, and even there it has a small effect on efficiency. We'd be slightly faster without it set, but I don't think it would affect any results. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Apr 6 11:15:42 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 6 Apr 2018 14:15:42 +0300 Subject: [aarch64-port-dev ] RFR: 8187472 - AARCH64: array_equals intrinsic doesn't use prefetch for large arrays In-Reply-To: References: <02e62700-efaf-918e-f04e-031dd4788aa0@bell-sw.com> Message-ID: <2ba45c72-0f95-fd4c-ab99-34000b70c6f3@bell-sw.com> Thank you for review On 06.04.2018 10:00, Dmitry Samersoff wrote: > Dmitrij, > > This version looks good to me. > > -Dmitry\S > > On 16/03/2018 19:21, Dmitrij Pochepko wrote: >> Hi Andrew, all, >> >> I modified patch according to your comments. >> >> First, regarding size statistics: I looked into string size statistics >> which was measured for JEP254: Compact Strings >> (http://docs.huihoo.com/javaone/2015/CON5483-Compact-Strings-A-Memory-Efficient-Internal-Representation-for-Strings.pdf). >> Conclusions are that 75% of strings <= 32 symbols, so we can take this >> number into account. This also means that changing string equals code to >> be capable of prefetching(and thus adding branch for that) is not >> practical. Arrays are another story. So, I split array equals and string >> equals. >> >> String equals remains basically unchanged(the only noticeable change is >> that I removed size calculations for UTF strings (asr to convert >> length-in-bytes into length-in-characters, and than converting it back >> via lsr). It save 2 instructions for this code path: about 5% >> improvement on small sizes. >> >> Array equals was completely re-written. >> >> For array equals I have 2 algorithms, controlled by vm option: >> UseSimpleArrayEquals. First algorithm(simple one) is basically the same >> as original one with slightly another branch logic. It seems like Cortex >> A7* series prefer shorter code, which fits better for speculative >> execution. All other CPUs I was able to check(Cortex A53 and Cavium h/w) >> prefer algorithm with large loop and possible prefetching. >> >> Regarding your comment about addresses at the end of memory page: you're >> right. It is indeed possible in theory to use this code for some >> substring, however, due to the nature of algorithm for array equals(it >> reads array length from array header directly and then jump to first >> array element), memory access will always be 8-byte aligned, then it's >> safe to use 8-byte loads for array tails. So, I believe this issue is >> now naturally resolved, since I left string equals logic unchanged. >> >> >> Now, benchmarks: >> >> I modified benchmark to have better measurements accuracy by increasing >> amount of data processed in each iteration >> (http://cr.openjdk.java.net/~dpochepk/8187472/ArrayAltEquals.java) and >> has following improvement average numbers for array equals: >> >> Cavium "ThunderX 2": >> length 1..8: 10-20% >> length 9..16: 1% >> length 17..32: 5-10% >> large(512+): almost 2 times >> >> Cavium "Thunder X": >> length 1..8: 1% >> length 9..16: 2-3% >> length 17..32: 5% >> large arrays(512+): up to 5 times >> >> Cortex A53 (R-Pi): >> all ranges are about 5% average (note: large results dispersion (about >> 10%) on R-PI) >> >> Cortex A73: >> basically no changes because implementation is almost the same (better >> by about 0.5% average, but dispersion is about 4%, so it's not a >> statistically significant result) >> >> >> More detailed benchmarking results can be found here: >> http://cr.openjdk.java.net/~dpochepk/8187472/array_equals_total.xls >> >> updated webrev: http://cr.openjdk.java.net/~dpochepk/8187472/webrev.08/ >> >> Testing: passed jtreg hotspot tests on AArch64 fastdebug build. no new >> failures found in comparison with non-patched build. >> >> I also additionally used "brute-force" test which checks all array >> equality combinations for any given length ranges: >> http://cr.openjdk.java.net/~dpochepk/8187472/ArrayEqTest.java >> >> >> Thanks, >> >> Dmitrij >> >> On 08.02.2018 13:11, Andrew Haley wrote: >>> On 07/02/18 19:39, Dmitrij Pochepko wrote: >>>> In general, this patch changes very short arrays handling(performing >>>> 8-byte read instead of few smaller reads, using the fact of 8-byte >>>> alignment) and jumping into stub with large 64-byte read loop for larger >>>> arrays). >>>> >>>> Measurements(measured array length 7,64,128,256,512,1024,100000. >>>> Improvement in %. 80% improvement means that new version is 80% faster, >>>> i.e. 5 times.): >>>> >>>> >>>> ThunderX: 2%, -4%, 0%, 2%, 32%, 55%, 80% >>>> >>>> ThunderX2: 0%, -3%, 17%, 19%, 29%, 31%, 47% >>>> >>>> Cortex A53 at 533MHz: 8%, -1%, -2%, 4%, 6%, 5%, 3% >>>> >>>> Cortex A73 at 903MHz: 8%, -3%, 0%, 7%, 8%, 9%, 8% >>>> >>>> Note: medium sizes are a bit slower because of additional branch >>>> added(which checks size and jumps to stub). >>> This indentation is messed up: >>> >>> @@ -5201,40 +5217,23 @@ >>> ??? // length == 4. >>> ??? if (log_elem_size > 0) >>> ????? lsl(cnt1, cnt1, log_elem_size); >>> -? ldr(tmp1, Address(a1, cnt1)); >>> -? ldr(tmp2, Address(a2, cnt1)); >>> +??? ldr(tmp1, Address(a1, cnt1)); >>> +??? ldr(tmp2, Address(a2, cnt1)); >>> >>> I'm not convinced that this works correctly if passed the address of a >>> pair >>> of arrays at the end of a page.? Maybe it isn't used on sub-arrays today >>> in HotSpot, but one day it might be. >>> >>> It pessimizes a very common case of strings, those of about 32 >>> characters. >>> Please think again.? Please also think about strings that are long enough >>> for the SIMD loop but differ in their early substrings. >>> > From ci_notify at linaro.org Sun Apr 8 10:09:58 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 8 Apr 2018 10:09:58 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <924857821.5325.1523182199006.JavaMail.jenkins@4a1669f5d0e4> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/097/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/13 pass: 7,591; fail: 726; error: 22 Build 1: aarch64/2018/jan/19 pass: 7,598; fail: 720; error: 23 Build 2: aarch64/2018/jan/21 pass: 7,595; fail: 717; error: 29 Build 3: aarch64/2018/feb/21 pass: 7,623; fail: 749; error: 27 Build 4: aarch64/2018/mar/15 pass: 7,693; fail: 692; error: 20 Build 5: aarch64/2018/mar/17 pass: 7,654; fail: 727; error: 24 Build 6: aarch64/2018/mar/19 pass: 7,657; fail: 722; error: 26 Build 7: aarch64/2018/mar/21 pass: 7,652; fail: 732; error: 21 Build 8: aarch64/2018/mar/23 pass: 7,629; fail: 752; error: 24 Build 9: aarch64/2018/mar/25 pass: 7,778; fail: 629; error: 20 Build 10: aarch64/2018/mar/27 pass: 7,773; fail: 634; error: 20 Build 11: aarch64/2018/mar/29 pass: 7,790; fail: 617; error: 20 Build 12: aarch64/2018/mar/31 pass: 7,766; fail: 643; error: 18 Build 13: aarch64/2018/apr/05 pass: 7,787; fail: 619; error: 21 Build 14: aarch64/2018/apr/07 pass: 7,781; fail: 632; error: 18 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/13 pass: 3,821; fail: 5; error: 4 Build 1: aarch64/2018/jan/19 pass: 3,825; fail: 5; error: 5 Build 2: aarch64/2018/jan/21 pass: 3,824; fail: 5; error: 6 Build 3: aarch64/2018/feb/21 pass: 3,831; fail: 6; error: 9 Build 4: aarch64/2018/mar/15 pass: 3,842; fail: 6; error: 4 Build 5: aarch64/2018/mar/17 pass: 3,842; fail: 6; error: 4 Build 6: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 7: aarch64/2018/mar/21 pass: 3,844; fail: 6; error: 2 Build 8: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 9: aarch64/2018/mar/25 pass: 3,844; fail: 6; error: 7 Build 10: aarch64/2018/mar/27 pass: 3,847; fail: 6; error: 4 Build 11: aarch64/2018/mar/29 pass: 3,849; fail: 6; error: 2 Build 12: aarch64/2018/mar/31 pass: 3,851; fail: 6 Build 13: aarch64/2018/apr/05 pass: 3,851; fail: 6 Build 14: aarch64/2018/apr/07 pass: 3,851; fail: 6; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/13 pass: 7,598; fail: 715; error: 26 Build 1: aarch64/2018/jan/19 pass: 7,620; fail: 700; error: 21 Build 2: aarch64/2018/jan/21 pass: 7,600; fail: 714; error: 27 Build 3: aarch64/2018/feb/21 pass: 7,656; fail: 716; error: 27 Build 4: aarch64/2018/mar/15 pass: 7,680; fail: 703; error: 22 Build 5: aarch64/2018/mar/17 pass: 7,670; fail: 711; error: 24 Build 6: aarch64/2018/mar/19 pass: 7,669; fail: 714; error: 22 Build 7: aarch64/2018/mar/21 pass: 7,675; fail: 711; error: 19 Build 8: aarch64/2018/mar/23 pass: 7,643; fail: 740; error: 22 Build 9: aarch64/2018/mar/25 pass: 7,811; fail: 599; error: 17 Build 10: aarch64/2018/mar/27 pass: 7,794; fail: 614; error: 19 Build 11: aarch64/2018/mar/29 pass: 7,823; fail: 585; error: 19 Build 12: aarch64/2018/mar/31 pass: 7,798; fail: 611; error: 18 Build 13: aarch64/2018/apr/05 pass: 7,816; fail: 593; error: 18 Build 14: aarch64/2018/apr/07 pass: 7,797; fail: 619; error: 15 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/13 pass: 3,819; fail: 5; error: 6 Build 1: aarch64/2018/jan/19 pass: 3,829; fail: 5; error: 1 Build 2: aarch64/2018/jan/21 pass: 3,827; fail: 5; error: 3 Build 3: aarch64/2018/feb/21 pass: 3,838; fail: 6; error: 2 Build 4: aarch64/2018/mar/15 pass: 3,845; fail: 6; error: 1 Build 5: aarch64/2018/mar/17 pass: 3,841; fail: 6; error: 5 Build 6: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 7: aarch64/2018/mar/21 pass: 3,841; fail: 6; error: 5 Build 8: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 9: aarch64/2018/mar/25 pass: 3,850; fail: 6; error: 1 Build 10: aarch64/2018/mar/27 pass: 3,848; fail: 6; error: 3 Build 11: aarch64/2018/mar/29 pass: 3,848; fail: 6; error: 3 Build 12: aarch64/2018/mar/31 pass: 3,850; fail: 6; error: 1 Build 13: aarch64/2018/apr/05 pass: 3,851; fail: 6 Build 14: aarch64/2018/apr/07 pass: 3,853; fail: 5; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.9, Server: 111.14 Client 66.9 / Client 2014-04-01 (43.00): 1.56x Server 111.14 / Server 2014-04-01 (71.00): 1.57x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2018-01-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/013/results/ 2018-01-20 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/019/results/ 2018-01-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/021/results/ 2018-02-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/052/results/ 2018-03-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/074/results/ 2018-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/076/results/ 2018-03-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/078/results/ 2018-03-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/080/results/ 2018-03-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/082/results/ 2018-03-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/084/results/ 2018-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/086/results/ 2018-03-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/088/results/ 2018-03-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/090/results/ 2018-04-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/095/results/ 2018-04-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/097/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Tue Apr 10 11:57:16 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 10 Apr 2018 11:57:16 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 10 on AArch64 Message-ID: <176356710.5664.1523361437930.JavaMail.jenkins@4a1669f5d0e4> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/summary/2018/099/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,432; fail: 714; error: 20 Build 1: aarch64/2017/sep/20 pass: 7,469; fail: 689; error: 22 Build 2: aarch64/2017/oct/06 pass: 7,467; fail: 731; error: 23 Build 3: aarch64/2017/oct/18 pass: 7,468; fail: 732; error: 24 Build 4: aarch64/2017/oct/19 pass: 7,474; fail: 728; error: 22 Build 5: aarch64/2017/oct/21 pass: 7,470; fail: 730; error: 24 Build 6: aarch64/2017/oct/25 pass: 7,477; fail: 730; error: 20 Build 7: aarch64/2017/oct/27 pass: 7,470; fail: 736; error: 21 Build 8: aarch64/2017/oct/29 pass: 7,468; fail: 738; error: 21 Build 9: aarch64/2017/oct/31 pass: 7,486; fail: 720; error: 21 Build 10: aarch64/2017/nov/01 pass: 7,472; fail: 734; error: 21 Build 11: aarch64/2018/jan/02 pass: 7,594; fail: 721; error: 24 Build 12: aarch64/2018/jan/03 pass: 7,565; fail: 753; error: 22 Build 13: aarch64/2018/jan/05 pass: 7,605; fail: 711; error: 24 Build 14: aarch64/2018/apr/09 pass: 7,586; fail: 734; error: 24 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,784 Build 1: aarch64/2017/sep/20 pass: 3,783; fail: 1 Build 2: aarch64/2017/oct/06 pass: 3,799; fail: 3 Build 3: aarch64/2017/oct/18 pass: 3,808; fail: 3 Build 4: aarch64/2017/oct/19 pass: 3,808; fail: 3 Build 5: aarch64/2017/oct/21 pass: 3,808; fail: 3 Build 6: aarch64/2017/oct/25 pass: 3,810; fail: 4 Build 7: aarch64/2017/oct/27 pass: 3,810; fail: 4 Build 8: aarch64/2017/oct/29 pass: 3,807; fail: 3; error: 4 Build 9: aarch64/2017/oct/31 pass: 3,808; fail: 4; error: 2 Build 10: aarch64/2017/nov/01 pass: 3,810; fail: 4 Build 11: aarch64/2018/jan/02 pass: 3,821; fail: 4; error: 1 Build 12: aarch64/2018/jan/03 pass: 3,820; fail: 3; error: 3 Build 13: aarch64/2018/jan/05 pass: 3,824; fail: 3; error: 1 Build 14: aarch64/2018/apr/09 pass: 3,831; fail: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,469; fail: 675; error: 22 Build 1: aarch64/2017/sep/20 pass: 7,452; fail: 705; error: 23 Build 2: aarch64/2017/oct/06 pass: 7,494; fail: 706; error: 21 Build 3: aarch64/2017/oct/18 pass: 7,460; fail: 740; error: 24 Build 4: aarch64/2017/oct/19 pass: 7,479; fail: 723; error: 22 Build 5: aarch64/2017/oct/21 pass: 7,492; fail: 711; error: 21 Build 6: aarch64/2017/oct/25 pass: 7,464; fail: 744; error: 19 Build 7: aarch64/2017/oct/27 pass: 7,473; fail: 732; error: 22 Build 8: aarch64/2017/oct/29 pass: 7,485; fail: 721; error: 21 Build 9: aarch64/2017/oct/31 pass: 7,471; fail: 733; error: 23 Build 10: aarch64/2017/nov/01 pass: 7,483; fail: 723; error: 21 Build 11: aarch64/2018/jan/02 pass: 7,538; fail: 779; error: 22 Build 12: aarch64/2018/jan/03 pass: 7,588; fail: 727; error: 25 Build 13: aarch64/2018/jan/05 pass: 7,594; fail: 716; error: 30 Build 14: aarch64/2018/apr/09 pass: 7,602; fail: 718; error: 24 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,782; error: 2 Build 1: aarch64/2017/sep/20 pass: 3,783; fail: 1 Build 2: aarch64/2017/oct/06 pass: 3,798; fail: 4 Build 3: aarch64/2017/oct/18 pass: 3,807; fail: 4 Build 4: aarch64/2017/oct/19 pass: 3,807; fail: 4 Build 5: aarch64/2017/oct/21 pass: 3,808; fail: 3 Build 6: aarch64/2017/oct/25 pass: 3,811; fail: 3 Build 7: aarch64/2017/oct/27 pass: 3,810; fail: 3; error: 1 Build 8: aarch64/2017/oct/29 pass: 3,807; fail: 4; error: 3 Build 9: aarch64/2017/oct/31 pass: 3,808; fail: 3; error: 3 Build 10: aarch64/2017/nov/01 pass: 3,810; fail: 4 Build 11: aarch64/2018/jan/02 pass: 3,820; fail: 3; error: 3 Build 12: aarch64/2018/jan/03 pass: 3,823; fail: 3 Build 13: aarch64/2018/jan/05 pass: 3,821; fail: 3; error: 4 Build 14: aarch64/2018/apr/09 pass: 3,827; fail: 3; error: 4 Previous results can be found here: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 67.21, Server: 111.14 Client 67.21 / Client 2014-04-01 (43.00): 1.56x Server 111.14 / Server 2014-04-01 (71.00): 1.57x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-10-04 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/276/results/ 2017-10-05 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/277/results/ 2017-10-07 pass rate: 11555/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/279/results/ 2017-10-19 pass rate: 11557/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/291/results/ 2017-10-20 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/292/results/ 2017-10-22 pass rate: 11557/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/294/results/ 2017-10-26 pass rate: 11557/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/298/results/ 2017-10-28 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/300/results/ 2017-10-30 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/302/results/ 2017-11-01 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/304/results/ 2017-11-02 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/305/results/ 2018-01-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/002/results/ 2018-01-06 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/003/results/ 2018-01-10 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/005/results/ 2018-04-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/099/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/ From yang.zhang at linaro.org Wed Apr 11 07:18:11 2018 From: yang.zhang at linaro.org (Yang Zhang) Date: Wed, 11 Apr 2018 15:18:11 +0800 Subject: [aarch64-port-dev ] AOT for AArch64: current status In-Reply-To: <6ed685f0-c851-d12f-1788-a896f4e0d162@redhat.com> References: <83f0e948-d002-6b71-e73f-6f65fce14e3b@redhat.com> <15f51315-3497-6c01-2ecb-1f758762e99e@redhat.com> <849a8fcf-85cd-b8c6-1134-9aea3877e9b7@redhat.com> <2c42186a-523e-6912-6eb0-36c7ee2be09f@redhat.com> <8b4a211e-44af-ed28-5abf-697d722771d1@redhat.com> <97d96f0e-43b0-beca-3b31-3dabc6073f3a@redhat.com> <8342caa0-e4d1-0250-02ab-c8f9cf8085bd@redhat.com> <6ed685f0-c851-d12f-1788-a896f4e0d162@redhat.com> Message-ID: Hi Andrew When I tested the new patch, I found there is a test case which is passed with release jdk build, but is failed with fastdebug/slowdebug jdk build. compiler/aot/cli/jaotc/CompileClassWithDebugTest.java With fastdebug: TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0] This failure results from "Fix out-of-range branch " patch https://github.com/theRealAph/graal/commit/d2ed61967b202cc9f623387619902315df20ede6 Regards Yang On 4 April 2018 at 01:28, Andrew Haley wrote: > I fixed a bug in Graal which was causing > compiler.aot.DeoptimizationTest to fail. > > I fixed the bug which was causing assertion failures due to branch out > of range. > > I pulled from the tip of Graal master. It should all be up to date > now. > > All pushed to https://github.com/theRealAph/graal.git aarch64-branch-overflows > > I'm still seeing some assertion failures, but they're not in my code > and I don't think they're anything to do with me. They all seem to do > with types not being registered. Updating Graal didn't help, so I > need to try to figure out why this isn't a problem on x86. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Wed Apr 11 13:58:56 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 11 Apr 2018 13:58:56 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 10 on AArch64 Message-ID: <303071377.5853.1523455137027.JavaMail.jenkins@4a1669f5d0e4> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/summary/2018/099/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/20 pass: 1,369; fail: 35; error: 1 Build 1: aarch64/2017/oct/04 pass: 1,419; fail: 12; error: 1 Build 2: aarch64/2017/oct/06 pass: 1,385; fail: 49 Build 3: aarch64/2017/oct/18 pass: 1,423; fail: 12 Build 4: aarch64/2017/oct/19 pass: 1,425; fail: 11 Build 5: aarch64/2017/oct/21 pass: 1,425; fail: 11; error: 1 Build 6: aarch64/2017/oct/25 pass: 1,428; fail: 10; error: 1 Build 7: aarch64/2017/oct/27 pass: 1,429; fail: 11 Build 8: aarch64/2017/oct/29 pass: 1,429; fail: 10; error: 1 Build 9: aarch64/2017/oct/31 pass: 1,429; fail: 11 Build 10: aarch64/2017/nov/01 pass: 1,429; fail: 11 Build 11: aarch64/2018/jan/02 pass: 1,587; fail: 11 Build 12: aarch64/2018/jan/03 pass: 1,586; fail: 12 Build 13: aarch64/2018/jan/05 pass: 1,586; fail: 12 Build 14: aarch64/2018/apr/09 pass: 1,592; fail: 10; error: 2; not run: 11,623 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,432; fail: 714; error: 20 Build 1: aarch64/2017/sep/20 pass: 7,469; fail: 689; error: 22 Build 2: aarch64/2017/oct/06 pass: 7,467; fail: 731; error: 23 Build 3: aarch64/2017/oct/18 pass: 7,468; fail: 732; error: 24 Build 4: aarch64/2017/oct/19 pass: 7,474; fail: 728; error: 22 Build 5: aarch64/2017/oct/21 pass: 7,470; fail: 730; error: 24 Build 6: aarch64/2017/oct/25 pass: 7,477; fail: 730; error: 20 Build 7: aarch64/2017/oct/27 pass: 7,470; fail: 736; error: 21 Build 8: aarch64/2017/oct/29 pass: 7,468; fail: 738; error: 21 Build 9: aarch64/2017/oct/31 pass: 7,486; fail: 720; error: 21 Build 10: aarch64/2017/nov/01 pass: 7,472; fail: 734; error: 21 Build 11: aarch64/2018/jan/02 pass: 7,594; fail: 721; error: 24 Build 12: aarch64/2018/jan/03 pass: 7,565; fail: 753; error: 22 Build 13: aarch64/2018/jan/05 pass: 7,605; fail: 711; error: 24 Build 14: aarch64/2018/apr/09 pass: 7,593; fail: 725; error: 26 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,784 Build 1: aarch64/2017/sep/20 pass: 3,783; fail: 1 Build 2: aarch64/2017/oct/06 pass: 3,799; fail: 3 Build 3: aarch64/2017/oct/18 pass: 3,808; fail: 3 Build 4: aarch64/2017/oct/19 pass: 3,808; fail: 3 Build 5: aarch64/2017/oct/21 pass: 3,808; fail: 3 Build 6: aarch64/2017/oct/25 pass: 3,810; fail: 4 Build 7: aarch64/2017/oct/27 pass: 3,810; fail: 4 Build 8: aarch64/2017/oct/29 pass: 3,807; fail: 3; error: 4 Build 9: aarch64/2017/oct/31 pass: 3,808; fail: 4; error: 2 Build 10: aarch64/2017/nov/01 pass: 3,810; fail: 4 Build 11: aarch64/2018/jan/02 pass: 3,821; fail: 4; error: 1 Build 12: aarch64/2018/jan/03 pass: 3,820; fail: 3; error: 3 Build 13: aarch64/2018/jan/05 pass: 3,824; fail: 3; error: 1 Build 14: aarch64/2018/apr/09 pass: 3,828; fail: 3; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/20 pass: 1,373; fail: 37 Build 1: aarch64/2017/oct/04 pass: 1,422; fail: 15 Build 2: aarch64/2017/oct/06 pass: 1,304; fail: 134; error: 1 Build 3: aarch64/2017/oct/18 pass: 1,427; fail: 13 Build 4: aarch64/2017/oct/19 pass: 1,427; fail: 13; error: 1 Build 5: aarch64/2017/oct/21 pass: 1,428; fail: 13; error: 1 Build 6: aarch64/2017/oct/25 pass: 1,431; fail: 12; error: 1 Build 7: aarch64/2017/oct/27 pass: 1,433; fail: 12 Build 8: aarch64/2017/oct/29 pass: 1,432; fail: 12; error: 1 Build 9: aarch64/2017/oct/31 pass: 1,433; fail: 12 Build 10: aarch64/2017/nov/01 pass: 1,433; fail: 12 Build 11: aarch64/2018/jan/02 pass: 1,591; fail: 12 Build 12: aarch64/2018/jan/03 pass: 1,592; fail: 10; error: 1 Build 13: aarch64/2018/jan/05 pass: 1,593; fail: 10 Build 14: aarch64/2018/apr/09 pass: 1,600; fail: 8; error: 1; not run: 11,623 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,469; fail: 675; error: 22 Build 1: aarch64/2017/sep/20 pass: 7,452; fail: 705; error: 23 Build 2: aarch64/2017/oct/06 pass: 7,494; fail: 706; error: 21 Build 3: aarch64/2017/oct/18 pass: 7,460; fail: 740; error: 24 Build 4: aarch64/2017/oct/19 pass: 7,479; fail: 723; error: 22 Build 5: aarch64/2017/oct/21 pass: 7,492; fail: 711; error: 21 Build 6: aarch64/2017/oct/25 pass: 7,464; fail: 744; error: 19 Build 7: aarch64/2017/oct/27 pass: 7,473; fail: 732; error: 22 Build 8: aarch64/2017/oct/29 pass: 7,485; fail: 721; error: 21 Build 9: aarch64/2017/oct/31 pass: 7,471; fail: 733; error: 23 Build 10: aarch64/2017/nov/01 pass: 7,483; fail: 723; error: 21 Build 11: aarch64/2018/jan/02 pass: 7,538; fail: 779; error: 22 Build 12: aarch64/2018/jan/03 pass: 7,588; fail: 727; error: 25 Build 13: aarch64/2018/jan/05 pass: 7,594; fail: 716; error: 30 Build 14: aarch64/2018/apr/09 pass: 7,617; fail: 695; error: 32 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,782; error: 2 Build 1: aarch64/2017/sep/20 pass: 3,783; fail: 1 Build 2: aarch64/2017/oct/06 pass: 3,798; fail: 4 Build 3: aarch64/2017/oct/18 pass: 3,807; fail: 4 Build 4: aarch64/2017/oct/19 pass: 3,807; fail: 4 Build 5: aarch64/2017/oct/21 pass: 3,808; fail: 3 Build 6: aarch64/2017/oct/25 pass: 3,811; fail: 3 Build 7: aarch64/2017/oct/27 pass: 3,810; fail: 3; error: 1 Build 8: aarch64/2017/oct/29 pass: 3,807; fail: 4; error: 3 Build 9: aarch64/2017/oct/31 pass: 3,808; fail: 3; error: 3 Build 10: aarch64/2017/nov/01 pass: 3,810; fail: 4 Build 11: aarch64/2018/jan/02 pass: 3,820; fail: 3; error: 3 Build 12: aarch64/2018/jan/03 pass: 3,823; fail: 3 Build 13: aarch64/2018/jan/05 pass: 3,821; fail: 3; error: 4 Build 14: aarch64/2018/apr/09 pass: 3,825; fail: 3; error: 6 Previous results can be found here: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 67.21, Server: 111.14 Client 67.21 / Client 2014-04-01 (43.00): 1.56x Server 111.14 / Server 2014-04-01 (71.00): 1.57x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-10-05 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/277/results/ 2017-10-07 pass rate: 11555/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/279/results/ 2017-10-19 pass rate: 11557/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/291/results/ 2017-10-20 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/292/results/ 2017-10-22 pass rate: 11557/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/294/results/ 2017-10-26 pass rate: 11557/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/298/results/ 2017-10-28 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/300/results/ 2017-10-30 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/302/results/ 2017-11-01 pass rate: 11558/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/304/results/ 2017-11-02 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/305/results/ 2018-01-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/002/results/ 2018-01-06 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/003/results/ 2018-01-10 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/005/results/ 2018-04-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/099/results/ 2018-04-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2018/099/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/ From dmitry.samersoff at bell-sw.com Sat Apr 14 17:24:48 2018 From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff) Date: Sat, 14 Apr 2018 20:24:48 +0300 Subject: [aarch64-port-dev ] JEP 328: Flight Recorder on AARCH64 platfrom Message-ID: <449ed692-6d69-6a82-4b7e-87819645f06e@bell-sw.com> Hi Everybody, As soon as preview patch form JFR is available now, I created a CR to test it on AARCH64 platform. See. JDK-8201564 -Dmitry From stuart.monteith at linaro.org Mon Apr 16 14:46:00 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 16 Apr 2018 15:46:00 +0100 Subject: [aarch64-port-dev ] hg: zgc/zgc: 208 new changesets In-Reply-To: <176fb138-1528-741d-6c10-6917cdec9100@oracle.com> References: <201804161348.w3GDmYYO006567@aojmv0008.oracle.com> <176fb138-1528-741d-6c10-6917cdec9100@oracle.com> Message-ID: Thanks for that Per - I do appreciate being able to rebase my aarch64 work on top of your periodic drops. I've gotten to the point where I am running with a slowdebug build running with: -XX:+VerifyOops -XX:+ZVerifyForwarding -XX:+ZVerifyMarking -Xint The benchmark I'm running is perhaps cruel and unusual, but even with the VM pinned to one CPU, there is an issue with verify_oop getting a bad address (0x8). BR, Stuart On 16 April 2018 at 15:02, Per Liden wrote: > FYI, this rebase brings the ZGC repo in sync with jdk/hs (as it looked mid > Thursday last week). As jdk/hs is closing we'll be shifting over to jdk/jdk > as upstream. > > cheers, > Per > > On 04/16/2018 03:48 PM, per.liden at oracle.com wrote: >> >> Changeset: 2520a95cddf7 >> Author: stefank >> Date: 2018-03-26 17:01 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2520a95cddf7 >> >> 8200292: Move PushAndMarkVerifyClosure::do_oop_work to >> concurrentMarkSweepGeneration.cpp >> Reviewed-by: tschatzl, sjohanss >> >> ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp >> ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.hpp >> >> Changeset: 64f9ebc85e67 >> Author: tschatzl >> Date: 2018-03-28 16:39 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/64f9ebc85e67 >> >> 8197573: Remove concurrent cleanup and secondary free list handling >> Summary: Remove secondary free list and all associated functionality, >> moving the cleanup work into the Cleanup pause instead. >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/concurrentMarkThread.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >> ! src/hotspot/share/gc/g1/g1CollectorState.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp >> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >> ! src/hotspot/share/gc/g1/g1Policy.cpp >> ! src/hotspot/share/gc/g1/g1Policy.hpp >> ! src/hotspot/share/gc/g1/g1RemSet.cpp >> ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp >> ! src/hotspot/share/gc/g1/g1_globals.hpp >> ! src/hotspot/share/gc/g1/heapRegion.cpp >> ! src/hotspot/share/gc/g1/heapRegion.hpp >> ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp >> ! src/hotspot/share/gc/g1/heapRegionSet.cpp >> ! src/hotspot/share/gc/g1/heapRegionSet.hpp >> ! src/hotspot/share/runtime/mutexLocker.cpp >> ! src/hotspot/share/runtime/mutexLocker.hpp >> ! >> test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java >> ! >> test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java >> >> Changeset: 29ad59abc54a >> Author: tschatzl >> Date: 2018-03-28 16:39 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/29ad59abc54a >> >> 8197928: Only enqueue deferred cards with references into regions that >> have a tracked remembered set during GC >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp >> >> Changeset: df9dcfff6628 >> Author: tschatzl >> Date: 2018-03-28 16:39 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/df9dcfff6628 >> >> 8197932: Better split work in rebuild remembered sets phase >> Summary: Let threads rebuilding remembered sets yield after every >> G1RebuildRemSetChunkSize (default: 256kB) sized memory area to improve TTSP. >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp >> ! src/hotspot/share/gc/g1/g1RemSet.cpp >> ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp >> ! src/hotspot/share/gc/g1/g1_globals.hpp >> >> Changeset: e79bbf1635da >> Author: tschatzl >> Date: 2018-03-28 16:39 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e79bbf1635da >> >> 8199326: Remove G1 gc time stamp logic >> Summary: G1 gc time stamp logic is unused completely after JDK-8180415, so >> removing it. >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/g1Allocator.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp >> ! src/hotspot/share/gc/g1/heapRegion.cpp >> ! src/hotspot/share/gc/g1/heapRegion.hpp >> >> Changeset: 6d5bd76650df >> Author: dcubed >> Date: 2018-03-28 12:04 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/6d5bd76650df >> >> 8199813: SIGSEGV in ThreadsList::includes() >> Summary: ThreadsListHandles cannot be used by JavaThreads that are not on >> the Threads list. >> Reviewed-by: eosterlund, gthornbr, dholmes, rehn >> >> ! src/hotspot/os/linux/os_linux.cpp >> ! src/hotspot/share/runtime/thread.cpp >> ! src/hotspot/share/runtime/threadSMR.cpp >> ! src/hotspot/share/runtime/vm_operations.cpp >> ! src/hotspot/share/runtime/vm_operations.hpp >> >> Changeset: ab0f93ba0507 >> Author: amenkov >> Date: 2018-03-28 12:10 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/ab0f93ba0507 >> >> 8198393: Instrumentation.retransformClasses() throws NullPointerException >> when handling a zero-length array >> Reviewed-by: sspitsyn, cjplummer >> >> ! >> src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >> + >> test/hotspot/jtreg/serviceability/jvmti/RetransformClassesZeroLength.java >> >> Changeset: 5af65ee8b77e >> Author: lmesnik >> Date: 2018-03-28 13:38 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5af65ee8b77e >> >> 8200091: [TESTBUG] Update jittester for jdk11 >> Reviewed-by: iignatyev >> >> ! test/hotspot/jtreg/testlibrary/jittester/Makefile >> >> Changeset: 4f7cfd7fdd50 >> Author: lmesnik >> Date: 2018-03-28 13:25 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/4f7cfd7fdd50 >> >> 8200187: Exclude 3 long-running tests from tier1 >> Reviewed-by: dholmes, cjplummer >> >> ! test/hotspot/jtreg/TEST.groups >> >> Changeset: dd76fcbda95f >> Author: kvn >> Date: 2018-03-28 17:20 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/dd76fcbda95f >> >> 8200383: Can't build on SPARC Hotspot with code which use math functions >> Summary: remove old hack which supports Solaris 8 and 9 >> Reviewed-by: erikj, ihse >> >> ! make/autoconf/libraries.m4 >> ! make/lib/Awt2dLibraries.gmk >> >> Changeset: 2ad3212a7dd9 >> Author: redestad >> Date: 2018-03-29 10:38 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2ad3212a7dd9 >> >> 8200238: Reduce number of exceptions created when calling >> MemberName$Factory::resolveOrNull >> Reviewed-by: lfoltan, acorn, dholmes >> >> ! src/hotspot/share/classfile/systemDictionary.cpp >> ! src/hotspot/share/prims/methodHandles.cpp >> ! src/hotspot/share/prims/methodHandles.hpp >> ! src/java.base/share/classes/java/lang/invoke/MemberName.java >> ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java >> >> Changeset: 7bad9c9efdf3 >> Author: shade >> Date: 2018-03-29 12:56 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7bad9c9efdf3 >> >> 8200423: Non-PCH build for x86_32 fails >> Reviewed-by: rkennke, stuefe >> >> ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp >> >> Changeset: a3453bbd5418 >> Author: tschatzl >> Date: 2018-03-29 14:07 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a3453bbd5418 >> >> 8199742: Clean up state flags in G1CollectorState >> Summary: Remove, merge and update naming of flags in G1CollectorState >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/g1Allocator.cpp >> ! src/hotspot/share/gc/g1/g1Analytics.cpp >> ! src/hotspot/share/gc/g1/g1Analytics.hpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp >> ! src/hotspot/share/gc/g1/g1CollectionSet.cpp >> ! src/hotspot/share/gc/g1/g1CollectorState.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1EvacFailure.cpp >> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >> ! src/hotspot/share/gc/g1/g1Policy.cpp >> ! src/hotspot/share/gc/g1/g1Policy.hpp >> ! src/hotspot/share/gc/g1/g1RootClosures.cpp >> ! src/hotspot/share/gc/g1/g1RootProcessor.cpp >> ! src/hotspot/share/gc/g1/g1YCTypes.hpp >> ! src/hotspot/share/gc/g1/heapRegion.cpp >> >> Changeset: 50a01910e00a >> Author: tschatzl >> Date: 2018-03-29 14:08 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/50a01910e00a >> >> 8151171: Bring g1ConcurrentMark files up to current coding conventions >> Summary: Improve method naming, bracketing, use of _g1h member and general >> cleanup. >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/concurrentMarkThread.cpp >> ! src/hotspot/share/gc/g1/concurrentMarkThread.hpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.hpp >> ! src/hotspot/share/gc/g1/g1OopClosures.hpp >> >> Changeset: 2bf8f2fc0710 >> Author: simonis >> Date: 2018-03-29 14:50 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2bf8f2fc0710 >> >> 8200360: MeetIncompatibleInterfaceArrays fails with >> "MeetIncompatibleInterfaceArrays0ASM.run() must be compiled at tier 0 !" >> Reviewed-by: kvn, thartmann >> >> ! >> test/hotspot/jtreg/compiler/types/TestMeetIncompatibleInterfaceArrays.java >> >> Changeset: 24aca5861b91 >> Author: redestad >> Date: 2018-03-29 15:05 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/24aca5861b91 >> >> 8200424: Windows build fails due to implicit jboolean to bool conversion >> Reviewed-by: shade, hseigel >> >> ! src/hotspot/share/prims/methodHandles.cpp >> >> Changeset: 5a757c0326c7 >> Author: tschatzl >> Date: 2018-03-29 17:15 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5a757c0326c7 >> >> 8200362: G1Mux2Closure should disable implicit oop verification >> Summary: To avoid the implicit oop verification provided by OopClosure and >> oop_iterate_no_header, let G1 verification closures inherit from >> ExtendedOopClosures and disable this verification. >> Reviewed-by: stefank, sjohanss >> >> ! src/hotspot/share/gc/g1/heapRegion.cpp >> >> Changeset: 7f5fca094057 >> Author: kvn >> Date: 2018-03-29 09:52 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7f5fca094057 >> >> 8200391: clean up test/hotspot/jtreg/ProblemList.txt (compiler related) >> Reviewed-by: mseledtsov >> >> ! test/hotspot/jtreg/ProblemList-graal.txt >> >> Changeset: 17c6ab93710e >> Author: dstewart >> Date: 2018-03-29 16:07 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/17c6ab93710e >> >> 8200251: AArch64::CPUFeature out of sync with VM_Version::Feature_Flag >> Summary: Added enums to CPUFeature to be in sync with >> VM_Version::Feature_Flag >> Reviewed-by: kvn, aph, shade >> >> ! >> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64.java >> >> Changeset: c42db4d81e33 >> Author: lucy >> Date: 2018-03-29 14:53 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/c42db4d81e33 >> >> 8200366: SIGSEGV in CodeHeapState::print_names() >> Summary: Temporary removed the failing function in diagnostic command >> until investigation is complete. Added checks to validate code blobs. >> Reviewed-by: kvn, thartmann >> >> ! src/hotspot/share/code/codeHeapState.cpp >> ! src/hotspot/share/services/diagnosticCommand.cpp >> >> Changeset: 1e11c8a238f7 >> Author: iklam >> Date: 2018-03-29 20:15 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1e11c8a238f7 >> >> 8183238: Obsolete CheckEndorsedAndExtDirs and remove checks for >> lib/endorsed and lib/ext >> Reviewed-by: dholmes, mchung, alanb >> >> ! src/bsd/doc/man/java.1 >> ! src/hotspot/share/runtime/arguments.cpp >> ! src/hotspot/share/runtime/globals.hpp >> ! src/linux/doc/man/java.1 >> ! src/solaris/doc/sun/man/man1/java.1 >> >> Changeset: a74836b05c28 >> Author: ccheung >> Date: 2018-03-29 21:48 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a74836b05c28 >> >> 8200078: [Graal] runtime/appcds/GraalWithLimitedMetaspace.java crashes in >> visit_all_interfaces >> Summary: stop CDS dumping right away when an OOM due to insufficient >> metaspace is encountered >> Reviewed-by: iklam, mseledtsov >> >> ! src/hotspot/share/memory/metaspace.cpp >> ! test/hotspot/jtreg/runtime/SharedArchiveFile/MaxMetaspaceSize.java >> ! test/hotspot/jtreg/runtime/appcds/GraalWithLimitedMetaspace.java >> >> Changeset: a569cb4425f3 >> Author: stuefe >> Date: 2018-03-30 06:31 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a569cb4425f3 >> >> 8191101: Show register content in hs-err file on assert >> Reviewed-by: adinn, clanger, simonis >> >> ! src/hotspot/os/posix/vmError_posix.cpp >> ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp >> ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp >> ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp >> ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp >> ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp >> ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp >> ! src/hotspot/share/runtime/arguments.cpp >> ! src/hotspot/share/runtime/globals.hpp >> ! src/hotspot/share/runtime/thread.cpp >> ! src/hotspot/share/utilities/debug.cpp >> ! src/hotspot/share/utilities/debug.hpp >> ! src/hotspot/share/utilities/vmError.cpp >> ! src/hotspot/share/utilities/vmError.hpp >> + test/hotspot/jtreg/runtime/ErrorHandling/ShowRegistersOnAssertTest.java >> >> Changeset: 16f53c9c7493 >> Author: kvn >> Date: 2018-03-30 07:47 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/16f53c9c7493 >> >> 8200461: MeetIncompatibleInterfaceArrays test fails with -Xcomp >> Summary: Add requires to run test only in Xmixed mode. >> Reviewed-by: simonis >> >> ! >> test/hotspot/jtreg/compiler/types/TestMeetIncompatibleInterfaceArrays.java >> >> Changeset: d6893a76c554 >> Author: poonam >> Date: 2018-03-30 18:46 +0000 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/d6893a76c554 >> >> 8199406: Performance drop with Java JDK 1.8.0_162-b32 >> Summary: Improve the nmethod unloading times by optimizing the search for >> an itable stub in VtableStubs array >> Reviewed-by: kvn, coleenp, tschatzl >> >> ! src/hotspot/share/code/codeBlob.cpp >> ! src/hotspot/share/code/codeBlob.hpp >> ! src/hotspot/share/code/compiledIC.cpp >> ! src/hotspot/share/code/vtableStubs.cpp >> ! src/hotspot/share/code/vtableStubs.hpp >> ! src/hotspot/share/oops/compiledICHolder.cpp >> ! src/hotspot/share/oops/compiledICHolder.hpp >> >> Changeset: be608cad0b2a >> Author: kbarrett >> Date: 2018-03-30 21:57 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/be608cad0b2a >> >> 8195972: Refactor oops in JNI to use the Access API >> Summary: Use Access API in JNIHandles >> Reviewed-by: coleenp, eosterlund >> >> ! src/hotspot/share/runtime/jniHandles.cpp >> ! src/hotspot/share/runtime/jniHandles.hpp >> ! src/hotspot/share/runtime/jniHandles.inline.hpp >> >> Changeset: 45071514f87a >> Author: shade >> Date: 2018-04-03 10:27 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/45071514f87a >> >> 8200438: Non-PCH x86_32 build failure: err_msg is not defined >> Reviewed-by: stuefe, zgu, stefank >> >> ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp >> >> Changeset: 8237a91c1cca >> Author: rkennke >> Date: 2018-04-03 13:15 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/8237a91c1cca >> >> 8199781: Don't use naked == for comparing oops >> Reviewed-by: coleenp, eosterlund, jrose >> >> ! src/hotspot/share/ci/ciEnv.cpp >> ! src/hotspot/share/ci/ciObjectFactory.cpp >> ! src/hotspot/share/classfile/classLoaderData.cpp >> ! src/hotspot/share/classfile/dictionary.cpp >> ! src/hotspot/share/classfile/javaClasses.cpp >> ! src/hotspot/share/classfile/protectionDomainCache.cpp >> ! src/hotspot/share/classfile/systemDictionary.cpp >> ! src/hotspot/share/code/dependencies.cpp >> ! src/hotspot/share/gc/shared/barrierSet.hpp >> ! src/hotspot/share/interpreter/bytecodeInterpreter.cpp >> ! src/hotspot/share/interpreter/interpreterRuntime.cpp >> ! src/hotspot/share/memory/universe.cpp >> + src/hotspot/share/oops/access.cpp >> ! src/hotspot/share/oops/access.hpp >> ! src/hotspot/share/oops/access.inline.hpp >> ! src/hotspot/share/oops/accessBackend.hpp >> + src/hotspot/share/oops/accessDecorators.hpp >> ! src/hotspot/share/oops/constantPool.cpp >> ! src/hotspot/share/oops/instanceKlass.cpp >> ! src/hotspot/share/oops/klassVtable.cpp >> ! src/hotspot/share/oops/objArrayKlass.cpp >> ! src/hotspot/share/oops/oop.hpp >> ! src/hotspot/share/prims/jni.cpp >> ! src/hotspot/share/prims/jvm.cpp >> ! src/hotspot/share/prims/methodHandles.cpp >> ! src/hotspot/share/prims/stackwalk.cpp >> ! src/hotspot/share/prims/unsafe.cpp >> ! src/hotspot/share/runtime/biasedLocking.cpp >> ! src/hotspot/share/runtime/handles.hpp >> ! src/hotspot/share/runtime/reflection.cpp >> ! src/hotspot/share/runtime/synchronizer.cpp >> ! src/hotspot/share/services/memoryManager.hpp >> ! src/hotspot/share/services/memoryPool.hpp >> ! src/hotspot/share/services/threadService.cpp >> ! src/hotspot/share/utilities/exceptions.cpp >> ! src/hotspot/share/utilities/growableArray.hpp >> >> Changeset: 0ed1370f52bb >> Author: lkorinth >> Date: 2018-04-03 12:05 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0ed1370f52bb >> >> 8200371: In g1, rename ConcurrentMarkThread to G1ConcurrentMarkThread >> Reviewed-by: tschatzl, sangheki >> >> - src/hotspot/share/gc/g1/concurrentMarkThread.cpp >> - src/hotspot/share/gc/g1/concurrentMarkThread.hpp >> - src/hotspot/share/gc/g1/concurrentMarkThread.inline.hpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp >> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp >> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp >> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >> ! src/hotspot/share/gc/g1/g1Policy.cpp >> ! src/hotspot/share/gc/g1/vm_operations_g1.cpp >> ! src/hotspot/share/prims/whitebox.cpp >> ! src/hotspot/share/runtime/thread.cpp >> >> Changeset: 89a886b7a9cf >> Author: redestad >> Date: 2018-04-03 12:55 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/89a886b7a9cf >> >> 8199717: Avoid calculating primordial thread stack bounds on VM startup >> Reviewed-by: dholmes, rehn, stuefe >> >> ! src/hotspot/os/linux/os_linux.cpp >> >> Changeset: a3fed4b041ac >> Author: rkennke >> Date: 2018-04-03 17:36 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a3fed4b041ac >> >> 8199780: SetMemory0 and CopyMemory0 in unsafe.cpp need to resolve their >> operands >> Reviewed-by: shade, zgu, eosterlund >> >> ! src/hotspot/share/prims/unsafe.cpp >> >> Changeset: 3614cbddd005 >> Author: mseledtsov >> Date: 2018-04-03 08:56 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/3614cbddd005 >> >> 8200126: [TESTBUG] Open source VM runtime signal tests >> Summary: Open sourced the signal tests, updated make files and test groups >> accordingly >> Reviewed-by: dholmes, ctornqvi, ihse >> >> ! make/test/JtregNativeHotspot.gmk >> ! test/hotspot/jtreg/TEST.groups >> + test/hotspot/jtreg/runtime/signal/README >> + test/hotspot/jtreg/runtime/signal/SigTestDriver.java >> + test/hotspot/jtreg/runtime/signal/TestSigalrm.java >> + test/hotspot/jtreg/runtime/signal/TestSigbus.java >> + test/hotspot/jtreg/runtime/signal/TestSigcld.java >> + test/hotspot/jtreg/runtime/signal/TestSigcont.java >> + test/hotspot/jtreg/runtime/signal/TestSigemt.java >> + test/hotspot/jtreg/runtime/signal/TestSigfpe.java >> + test/hotspot/jtreg/runtime/signal/TestSigfreeze.java >> + test/hotspot/jtreg/runtime/signal/TestSighup.java >> + test/hotspot/jtreg/runtime/signal/TestSigill.java >> + test/hotspot/jtreg/runtime/signal/TestSigint.java >> + test/hotspot/jtreg/runtime/signal/TestSigiot.java >> + test/hotspot/jtreg/runtime/signal/TestSiglost.java >> + test/hotspot/jtreg/runtime/signal/TestSiglwp.java >> + test/hotspot/jtreg/runtime/signal/TestSigpipe.java >> + test/hotspot/jtreg/runtime/signal/TestSigpoll.java >> + test/hotspot/jtreg/runtime/signal/TestSigprof.java >> + test/hotspot/jtreg/runtime/signal/TestSigpwr.java >> + test/hotspot/jtreg/runtime/signal/TestSigquit.java >> + test/hotspot/jtreg/runtime/signal/TestSigsegv.java >> + test/hotspot/jtreg/runtime/signal/TestSigstop.java >> + test/hotspot/jtreg/runtime/signal/TestSigsys.java >> + test/hotspot/jtreg/runtime/signal/TestSigterm.java >> + test/hotspot/jtreg/runtime/signal/TestSigthaw.java >> + test/hotspot/jtreg/runtime/signal/TestSigtrap.java >> + test/hotspot/jtreg/runtime/signal/TestSigtstp.java >> + test/hotspot/jtreg/runtime/signal/TestSigttin.java >> + test/hotspot/jtreg/runtime/signal/TestSigttou.java >> + test/hotspot/jtreg/runtime/signal/TestSigurg.java >> + test/hotspot/jtreg/runtime/signal/TestSigusr1.java >> + test/hotspot/jtreg/runtime/signal/TestSigusr2.java >> + test/hotspot/jtreg/runtime/signal/TestSigvtalrm.java >> + test/hotspot/jtreg/runtime/signal/TestSigwinch.java >> + test/hotspot/jtreg/runtime/signal/TestSigxcpu.java >> + test/hotspot/jtreg/runtime/signal/TestSigxfsz.java >> + test/hotspot/jtreg/runtime/signal/TestSigxres.java >> + test/hotspot/jtreg/runtime/signal/exesigtest.c >> >> Changeset: 0ab2411f270d >> Author: rwestberg >> Date: 2018-03-28 15:30 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0ab2411f270d >> >> 8199619: Building HotSpot on Windows should define NOMINMAX >> Reviewed-by: erikj, kbarrett, ihse >> >> ! make/autoconf/flags-cflags.m4 >> >> Changeset: 9a04cc89dde0 >> Author: tschatzl >> Date: 2018-04-04 11:21 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/9a04cc89dde0 >> >> 8200234: Cleanup Remark and Cleanup pause code >> Summary: Remove redundant methods, factor out verification code and >> simplify code in Remark and Cleanup pause code. >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/g1CollectorState.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >> ! src/hotspot/share/gc/g1/g1Policy.cpp >> ! src/hotspot/share/gc/g1/heapRegion.inline.hpp >> >> Changeset: 8bad6c08a732 >> Author: tschatzl >> Date: 2018-04-04 11:21 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/8bad6c08a732 >> >> 8200255: Remove G1CMTask::_concurrent >> Reviewed-by: sangheki, sjohanss >> >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> >> Changeset: 55f8f5635ef7 >> Author: tschatzl >> Date: 2018-04-04 11:21 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/55f8f5635ef7 >> >> 8200074: Remove G1ConcurrentMark::_concurrent_marking_in_progress >> Reviewed-by: sjohanss, sangheki >> >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> >> Changeset: 2fef34f04314 >> Author: ehelin >> Date: 2018-04-04 10:12 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2fef34f04314 >> >> 8200626: Restore history for g1ConcurrentMarkThread.* >> Reviewed-by: shade, sjohanss >> >> - src/hotspot/share/gc/g1/concurrentMarkThread.cpp >> - src/hotspot/share/gc/g1/concurrentMarkThread.hpp >> - src/hotspot/share/gc/g1/concurrentMarkThread.inline.hpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp >> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp >> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp >> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >> ! src/hotspot/share/gc/g1/g1Policy.cpp >> ! src/hotspot/share/gc/g1/vm_operations_g1.cpp >> ! src/hotspot/share/prims/whitebox.cpp >> ! src/hotspot/share/runtime/thread.cpp >> >> Changeset: 8263950638ed >> Author: ehelin >> Date: 2018-04-04 11:25 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/8263950638ed >> >> Merge >> >> ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp >> ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp >> >> Changeset: 3569b528972e >> Author: pliden >> Date: 2018-04-04 11:59 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/3569b528972e >> >> 8200429: Adjust object pinning interface on CollectedHeap >> Reviewed-by: dholmes, rkennke >> >> ! src/hotspot/share/gc/shared/collectedHeap.cpp >> ! src/hotspot/share/gc/shared/collectedHeap.hpp >> ! src/hotspot/share/prims/jni.cpp >> >> Changeset: 1a1a69219637 >> Author: pliden >> Date: 2018-04-04 11:59 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1a1a69219637 >> >> 8200607: Add missing include dependency in bitMap.hpp >> Reviewed-by: shade, stefank >> >> ! src/hotspot/share/utilities/bitMap.hpp >> >> Changeset: 015af70b9a1d >> Author: shade >> Date: 2018-04-04 12:06 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/015af70b9a1d >> >> 8200608: Build failures after JDK-8191101 (Show register content in hs-err >> file on assert) >> Reviewed-by: dholmes, tschatzl >> >> ! src/hotspot/share/utilities/debug.cpp >> >> Changeset: f1d2b6c0693b >> Author: tschatzl >> Date: 2018-04-04 14:51 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/f1d2b6c0693b >> >> 8200305: Update gc,liveness output with remset state after rebuild remset >> concurrently changes >> Reviewed-by: sjohanss, sangheki >> >> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >> ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp >> ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp >> >> Changeset: 46b2f783116c >> Author: dstewart >> Date: 2018-03-30 13:39 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/46b2f783116c >> >> 8200524: AArch64: CPUFeature and Flag enums are not passed through JVMCI >> Summary: AArch64 VM_Version::features and flags are correspondingly set in >> CPUFeature and Flags >> Reviewed-by: kvn, fyang >> >> ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp >> ! >> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.aarch64/src/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotJVMCIBackendFactory.java >> ! >> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.aarch64/src/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotVMConfig.java >> >> Changeset: c39f20946b37 >> Author: dpochepk >> Date: 2018-04-04 23:02 +0300 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/c39f20946b37 >> >> 8200627: aarch32 - Broken build after JDK-8198949 >> Reviewed-by: shade, eosterlund >> Contributed-by: boris.ulasevich at bell-sw.com >> >> ! src/hotspot/cpu/arm/gc/g1/g1BarrierSetAssembler_arm.hpp >> ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.hpp >> ! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp >> ! src/hotspot/cpu/arm/gc/shared/modRefBarrierSetAssembler_arm.hpp >> ! src/hotspot/cpu/arm/stubGenerator_arm.cpp >> >> Changeset: e862d3c78123 >> Author: dpochepk >> Date: 2018-04-04 23:05 +0300 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e862d3c78123 >> >> 8200628: aarch32 - Broken build after JDK-8199809 >> Reviewed-by: shade, coleenp >> Contributed-by: boris.ulasevich at bell-sw.com >> >> ! src/hotspot/cpu/arm/interpreterRT_arm.cpp >> >> Changeset: 0bb0c2f27ca9 >> Author: kbarrett >> Date: 2018-04-04 18:19 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0bb0c2f27ca9 >> >> 8200630: Globally suppress Visual Studio warning C4351 >> Summary: Globally suppress warning, remove sole instance of local >> suppression. >> Reviewed-by: gtriantafill, tschatzl >> >> ! src/hotspot/share/gc/shared/oopStorage.cpp >> ! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp >> >> Changeset: a1a7456dd8b9 >> Author: hseigel >> Date: 2018-04-05 13:19 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a1a7456dd8b9 >> >> 8200261: Regression with JVM anonymous class >> Summary: Restore resolved anonymous class when creating a new constantpool >> because of overpass methods >> Reviewed-by: coleenp, lfoltan >> >> ! src/hotspot/share/classfile/classFileParser.cpp >> ! src/hotspot/share/classfile/defaultMethods.cpp >> ! src/hotspot/share/oops/instanceKlass.hpp >> + test/hotspot/jtreg/runtime/defineAnonClass/UnsafeDefMeths.java >> >> Changeset: fa26e7c6efb7 >> Author: gadams >> Date: 2018-04-05 11:18 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/fa26e7c6efb7 >> >> 8199782: Fix compilation warnings detected by Solaris Developer Studio >> 12.6 >> Reviewed-by: sspitsyn, dholmes, ihse >> >> ! make/hotspot/lib/CompileJvm.gmk >> ! src/java.base/solaris/native/libjvm_db/libjvm_db.c >> ! test/fmw/gtest/src/gtest.cc >> ! test/hotspot/jtreg/runtime/libadimalloc.solaris.sparc/liboverflow.c >> >> Changeset: 0ee57b9b376c >> Author: chegar >> Date: 2018-03-23 21:39 +0000 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0ee57b9b376c >> >> 8200181: Remove superflous non-IPv4 code from >> Java_java_net_TwoStacksPlainSocketImpl_socketListen >> Reviewed-by: alanb >> >> ! src/java.base/windows/native/libnet/TwoStacksPlainSocketImpl.c >> >> Changeset: 1f14faf358fb >> Author: bpb >> Date: 2018-03-23 15:05 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1f14faf358fb >> >> 8180410: ByteArrayOutputStream should not throw IOExceptions >> Summary: Add ByteArrayOutputStream.writeBytes() >> Reviewed-by: rriggs, smarks >> >> ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java >> + test/jdk/java/io/ByteArrayOutputStream/Write.java >> - test/jdk/java/io/ByteArrayOutputStream/WriteBounds.java >> >> Changeset: 56a5f899e882 >> Author: jjg >> Date: 2018-03-23 17:28 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/56a5f899e882 >> >> 8199902: {@docRoot} references need to be updated to reflect new >> module/package structure >> Reviewed-by: ksrini >> >> ! src/jdk.compiler/share/classes/com/sun/source/doctree/package-info.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/package-info.java >> ! src/jdk.javadoc/share/classes/com/sun/javadoc/ClassDoc.java >> ! src/jdk.javadoc/share/classes/com/sun/javadoc/Doc.java >> ! src/jdk.javadoc/share/classes/com/sun/javadoc/PackageDoc.java >> ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java >> ! src/jdk.javadoc/share/classes/module-info.java >> >> Changeset: f14852315495 >> Author: shinyafox >> Date: 2018-03-24 14:43 +0900 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/f14852315495 >> >> 8199762: JShell API: Failed to detect override when snippet to be >> overridden has been changed before >> Reviewed-by: rfield >> >> ! src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java >> ! src/jdk.jshell/share/classes/jdk/jshell/Unit.java >> ! test/langtools/jdk/jshell/MethodsTest.java >> >> Changeset: 1d3139252c1c >> Author: alanb >> Date: 2018-03-24 08:49 +0000 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1d3139252c1c >> >> 8200179: (se) More Selector cleanup >> Reviewed-by: bpb >> >> ! make/CompileJavaModules.gmk >> ! make/mapfiles/libnio/mapfile-linux >> ! make/mapfiles/libnio/mapfile-macosx >> ! make/mapfiles/libnio/mapfile-solaris >> - src/java.base/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java >> - src/java.base/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java >> - src/java.base/share/classes/sun/nio/ch/PollSelectorProvider.java >> ! src/java.base/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java >> ! src/java.base/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java >> ! src/java.base/solaris/classes/sun/nio/ch/EventPortSelectorImpl.java >> - src/java.base/solaris/classes/sun/nio/ch/EventPortWrapper.java >> - src/java.base/unix/classes/sun/nio/ch/PollArrayWrapper.java >> ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java >> + src/java.base/unix/classes/sun/nio/ch/PollSelectorProvider.java >> ! src/java.base/unix/native/libnio/ch/Net.c >> - src/java.base/unix/native/libnio/ch/PollArrayWrapper.c >> + src/java.base/unix/native/libnio/ch/PollSelectorImpl.c >> ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java >> ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java >> ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java >> >> Changeset: 5bfe30bb50a2 >> Author: dholmes >> Date: 2018-03-26 00:33 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5bfe30bb50a2 >> >> 8200213: Configure broken on MIPS >> Reviewed-by: erikj, stuefe, dholmes, ihse >> Contributed-by: Ao Qi >> >> ! make/autoconf/flags.m4 >> >> Changeset: b39bc2eb8325 >> Author: jlahoda >> Date: 2018-03-26 11:42 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b39bc2eb8325 >> >> 8196519: Incomplete classpath causes infinite recursion in >> Resolve.isAccessible >> Summary: ErrorType.getEnclosingType returns noType rather than self. >> Reviewed-by: mcimadamore, cushon >> >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java >> + >> test/langtools/tools/javac/processing/model/MissingClassRecursiveAccessible.java >> >> Changeset: 7b8696b3b972 >> Author: shade >> Date: 2018-03-26 15:09 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7b8696b3b972 >> >> 8200118: [TESTBUG] String concat tests should test toString() application >> order >> Reviewed-by: psandoz, redestad >> >> + test/jdk/java/lang/String/concat/ImplicitStringConcatOrder.java >> >> Changeset: 458c790b6995 >> Author: sundar >> Date: 2018-03-26 19:27 +0530 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/458c790b6995 >> >> 8200215: 17th loop of "let foo = ''"; throws ReferenceError >> Reviewed-by: jlaskey, attila, hannesw >> >> ! >> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java >> + test/nashorn/script/trusted/JDK-8200215.js >> >> Changeset: b64cd942ac7a >> Author: shade >> Date: 2018-03-26 20:20 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b64cd942ac7a >> >> 8200241: [TESTBUG] java/lang/String/concat/ tests should not force >> source/target = 9 anymore >> Reviewed-by: redestad, psandoz >> >> ! test/jdk/java/lang/String/concat/CompactStringsInitialCoder.java >> ! test/jdk/java/lang/String/concat/ImplicitStringConcat.java >> ! test/jdk/java/lang/String/concat/ImplicitStringConcatArgCount.java >> ! test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java >> ! test/jdk/java/lang/String/concat/ImplicitStringConcatMany.java >> ! test/jdk/java/lang/String/concat/ImplicitStringConcatManyLongs.java >> ! test/jdk/java/lang/String/concat/ImplicitStringConcatOrder.java >> ! >> test/jdk/java/lang/String/concat/ImplicitStringConcatShapes-head.template >> ! test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java >> >> Changeset: fd608d605e2f >> Author: ihse >> Date: 2018-03-26 20:44 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/fd608d605e2f >> >> 8200229: Simplify building of libjsig >> Reviewed-by: erikj >> >> ! make/Main.gmk >> - make/hotspot/lib/CompileLibjsig.gmk >> ! make/lib/Lib-java.base.gmk >> >> Changeset: 4269e701448e >> Author: serb >> Date: 2018-03-26 16:09 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/4269e701448e >> >> 8200198: javah man pages were not removed by JDK-8191054 >> Reviewed-by: erikj, alanb >> >> - src/bsd/doc/man/ja/javah.1 >> ! src/bsd/doc/man/java.1 >> ! src/bsd/doc/man/javac.1 >> ! src/bsd/doc/man/javadoc.1 >> - src/bsd/doc/man/javah.1 >> ! src/bsd/doc/man/javap.1 >> ! src/bsd/doc/man/jdb.1 >> ! src/linux/doc/man/ja/java.1 >> ! src/linux/doc/man/ja/javac.1 >> ! src/linux/doc/man/ja/javadoc.1 >> - src/linux/doc/man/ja/javah.1 >> ! src/linux/doc/man/ja/javap.1 >> ! src/linux/doc/man/ja/jdb.1 >> ! src/linux/doc/man/java.1 >> ! src/linux/doc/man/javac.1 >> ! src/linux/doc/man/javadoc.1 >> - src/linux/doc/man/javah.1 >> ! src/linux/doc/man/javap.1 >> ! src/linux/doc/man/jdb.1 >> ! src/solaris/doc/sun/man/man1/ja/java.1 >> ! src/solaris/doc/sun/man/man1/ja/javac.1 >> ! src/solaris/doc/sun/man/man1/ja/javadoc.1 >> - src/solaris/doc/sun/man/man1/ja/javah.1 >> ! src/solaris/doc/sun/man/man1/ja/javap.1 >> ! src/solaris/doc/sun/man/man1/ja/jdb.1 >> ! src/solaris/doc/sun/man/man1/java.1 >> ! src/solaris/doc/sun/man/man1/javac.1 >> ! src/solaris/doc/sun/man/man1/javadoc.1 >> - src/solaris/doc/sun/man/man1/javah.1 >> ! src/solaris/doc/sun/man/man1/javap.1 >> ! src/solaris/doc/sun/man/man1/jdb.1 >> >> Changeset: e9cb414f94eb >> Author: erikj >> Date: 2018-03-26 16:24 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e9cb414f94eb >> >> 8198652: Stop linking with -base:0x8000000 on Windows >> Reviewed-by: tbell, ihse, stuefe >> >> ! make/autoconf/flags-ldflags.m4 >> >> Changeset: 7f3986bad197 >> Author: igerasim >> Date: 2018-03-26 17:30 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7f3986bad197 >> >> 8199843: Optimize Integer/Long.highestOneBit() >> Reviewed-by: redestad, plevart >> >> ! src/java.base/share/classes/java/lang/Integer.java >> ! src/java.base/share/classes/java/lang/Long.java >> >> Changeset: d2fd2581325b >> Author: bpatel >> Date: 2018-03-26 18:07 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/d2fd2581325b >> >> 8199278: Javadoc search results does not link to anchors on a page >> Reviewed-by: jjg, ksrini >> >> ! >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java >> ! >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java >> ! >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js >> ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java >> ! test/langtools/jdk/javadoc/doclet/testSearch/pkg/AnotherClass.java >> >> Changeset: ce86061aff12 >> Author: bpatel >> Date: 2018-03-26 21:30 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/ce86061aff12 >> >> 8199705: Docs.gmk needs to be updated to remove the -html5 option >> Reviewed-by: erikj >> >> ! make/Docs.gmk >> >> Changeset: 752ecccb0b7f >> Author: cushon >> Date: 2018-03-27 13:48 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/752ecccb0b7f >> >> 8200301: deduplicate lambda methods >> Reviewed-by: vromero, mcimadamore >> >> ! >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >> + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java >> + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeHasher.java >> ! >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties >> ! >> test/langtools/tools/javac/annotations/typeAnnotations/classfile/InstanceInitializer.java >> ! >> test/langtools/tools/javac/annotations/typeAnnotations/classfile/StaticInitializer.java >> ! >> test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java >> + test/langtools/tools/javac/diags/examples/LambdaDeduplicate.java >> + test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> + test/langtools/tools/javac/lambda/deduplication/DeduplicationTest.java >> >> Changeset: e376090dc07e >> Author: alanb >> Date: 2018-03-27 19:29 +0100 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e376090dc07e >> >> 8200256: java/nio/channels/AsynchronousChannelGroup/Basic.java fails >> intermittently >> Reviewed-by: chegar >> >> ! make/mapfiles/libnio/mapfile-linux >> ! make/mapfiles/libnio/mapfile-macosx >> ! make/mapfiles/libnio/mapfile-solaris >> ! src/java.base/linux/classes/sun/nio/ch/EPollPort.java >> ! src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java >> ! src/java.base/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java >> ! src/java.base/share/classes/sun/nio/ch/IOUtil.java >> ! src/java.base/unix/native/libnio/ch/IOUtil.c >> >> Changeset: 5812849b5027 >> Author: igerasim >> Date: 2018-03-27 13:22 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5812849b5027 >> >> 8198358: Align organization of TwoStacksPlainSocketImp with >> DualStackPlainSocketImpl [win] >> Reviewed-by: chegar, clanger >> >> ! src/java.base/unix/native/libnet/PlainSocketImpl.c >> ! src/java.base/windows/classes/java/net/DualStackPlainSocketImpl.java >> ! src/java.base/windows/classes/java/net/TwoStacksPlainSocketImpl.java >> ! src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c >> ! src/java.base/windows/native/libnet/TwoStacksPlainSocketImpl.c >> ! test/jdk/java/net/Socket/AddressTest.java >> ! test/jdk/java/net/Socket/B6210227.java >> ! test/jdk/java/net/Socket/CloseAvailable.java >> ! test/jdk/java/net/Socket/DeadlockTest.java >> ! test/jdk/java/net/Socket/HttpProxy.java >> ! test/jdk/java/net/Socket/InheritHandle.java >> ! test/jdk/java/net/Socket/InheritTimeout.java >> ! test/jdk/java/net/Socket/LingerTest.java >> ! test/jdk/java/net/Socket/LinkLocal.java >> ! test/jdk/java/net/Socket/ProxyCons.java >> ! test/jdk/java/net/Socket/RST.java >> ! test/jdk/java/net/Socket/ReadTimeout.java >> ! test/jdk/java/net/Socket/SetSoLinger.java >> ! test/jdk/java/net/Socket/ShutdownInput.java >> ! test/jdk/java/net/Socket/SocksConnectTimeout.java >> ! test/jdk/java/net/Socket/TestAfterClose.java >> ! test/jdk/java/net/Socket/TestClose.java >> ! test/jdk/java/net/Socket/TestTcpNoDelay.java >> ! test/jdk/java/net/Socket/Timeout.java >> ! test/jdk/java/net/Socket/TrafficClass.java >> ! test/jdk/java/net/Socket/UrgentDataTest.java >> ! test/jdk/java/net/Socket/asyncClose/AsyncClose.java >> ! test/jdk/java/net/Socket/asyncClose/BrokenPipe.java >> ! test/jdk/java/net/Socket/setReuseAddress/Basic.java >> ! test/jdk/java/net/Socket/setReuseAddress/Restart.java >> ! test/jdk/java/net/SocketInputStream/SocketClosedException.java >> ! test/jdk/java/net/SocketInputStream/SocketTimeout.java >> ! test/jdk/java/net/SocketOption/ImmutableOptions.java >> ! test/jdk/java/net/SocketOption/MinimumRcvBufferSize.java >> ! test/jdk/java/net/SocketOption/SupportedOptionsSet.java >> ! test/jdk/java/net/SocketOption/UnsupportedOptionsTest.java >> >> Changeset: f76e1ac74f28 >> Author: redestad >> Date: 2018-03-28 00:45 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/f76e1ac74f28 >> >> 8200289: Reduce number of exceptions created when calling >> Lookup::canBeCached >> Reviewed-by: sundar, psandoz >> >> ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> >> Changeset: b6671a111395 >> Author: jjg >> Date: 2018-03-27 16:25 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b6671a111395 >> >> 8199465: {@docRoot} references need to be updated to reflect new >> module/package structure >> Reviewed-by: martin, alanb, chegar >> >> ! src/java.base/share/classes/java/lang/CharSequence.java >> ! src/java.base/share/classes/java/lang/Comparable.java >> ! src/java.base/share/classes/java/lang/ProcessHandle.java >> ! src/java.base/share/classes/java/lang/String.java >> ! src/java.base/share/classes/java/lang/Thread.java >> ! src/java.base/share/classes/java/lang/UnsupportedOperationException.java >> ! src/java.base/share/classes/java/lang/module/Configuration.java >> ! src/java.base/share/classes/java/time/Duration.java >> ! src/java.base/share/classes/java/time/Instant.java >> ! src/java.base/share/classes/java/time/LocalDate.java >> ! src/java.base/share/classes/java/time/LocalDateTime.java >> ! src/java.base/share/classes/java/time/LocalTime.java >> ! src/java.base/share/classes/java/time/MonthDay.java >> ! src/java.base/share/classes/java/time/OffsetDateTime.java >> ! src/java.base/share/classes/java/time/OffsetTime.java >> ! src/java.base/share/classes/java/time/Period.java >> ! src/java.base/share/classes/java/time/Year.java >> ! src/java.base/share/classes/java/time/YearMonth.java >> ! src/java.base/share/classes/java/time/ZoneId.java >> ! src/java.base/share/classes/java/time/ZoneOffset.java >> ! src/java.base/share/classes/java/time/ZonedDateTime.java >> ! src/java.base/share/classes/java/time/chrono/HijrahDate.java >> ! src/java.base/share/classes/java/time/chrono/JapaneseDate.java >> ! src/java.base/share/classes/java/time/chrono/MinguoDate.java >> ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java >> ! src/java.base/share/classes/java/util/AbstractCollection.java >> ! src/java.base/share/classes/java/util/AbstractList.java >> ! src/java.base/share/classes/java/util/AbstractMap.java >> ! src/java.base/share/classes/java/util/AbstractQueue.java >> ! src/java.base/share/classes/java/util/AbstractSequentialList.java >> ! src/java.base/share/classes/java/util/AbstractSet.java >> ! src/java.base/share/classes/java/util/ArrayDeque.java >> ! src/java.base/share/classes/java/util/ArrayList.java >> ! src/java.base/share/classes/java/util/Arrays.java >> ! src/java.base/share/classes/java/util/Collection.java >> ! src/java.base/share/classes/java/util/Collections.java >> ! src/java.base/share/classes/java/util/Comparator.java >> ! src/java.base/share/classes/java/util/Deque.java >> ! src/java.base/share/classes/java/util/EnumMap.java >> ! src/java.base/share/classes/java/util/EnumSet.java >> ! src/java.base/share/classes/java/util/HashMap.java >> ! src/java.base/share/classes/java/util/HashSet.java >> ! src/java.base/share/classes/java/util/Hashtable.java >> ! src/java.base/share/classes/java/util/IdentityHashMap.java >> ! src/java.base/share/classes/java/util/Iterator.java >> ! src/java.base/share/classes/java/util/LinkedHashMap.java >> ! src/java.base/share/classes/java/util/LinkedHashSet.java >> ! src/java.base/share/classes/java/util/LinkedList.java >> ! src/java.base/share/classes/java/util/List.java >> ! src/java.base/share/classes/java/util/ListIterator.java >> ! src/java.base/share/classes/java/util/Map.java >> ! src/java.base/share/classes/java/util/NavigableMap.java >> ! src/java.base/share/classes/java/util/NavigableSet.java >> ! src/java.base/share/classes/java/util/PriorityQueue.java >> ! src/java.base/share/classes/java/util/Queue.java >> ! src/java.base/share/classes/java/util/RandomAccess.java >> ! src/java.base/share/classes/java/util/ResourceBundle.java >> ! src/java.base/share/classes/java/util/Set.java >> ! src/java.base/share/classes/java/util/SortedMap.java >> ! src/java.base/share/classes/java/util/SortedSet.java >> ! src/java.base/share/classes/java/util/TreeMap.java >> ! src/java.base/share/classes/java/util/TreeSet.java >> ! src/java.base/share/classes/java/util/Vector.java >> ! src/java.base/share/classes/java/util/WeakHashMap.java >> ! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java >> ! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java >> ! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java >> ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java >> ! >> src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java >> ! >> src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java >> ! src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java >> ! >> src/java.base/share/classes/java/util/concurrent/ConcurrentNavigableMap.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/CopyOnWriteArraySet.java >> ! src/java.base/share/classes/java/util/concurrent/DelayQueue.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/SynchronousQueue.java >> ! src/java.base/share/classes/java/util/concurrent/TransferQueue.java >> ! src/java.base/share/classes/javax/net/ssl/SNIHostName.java >> >> Changeset: 951f29c9aef5 >> Author: jlahoda >> Date: 2018-03-28 10:24 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/951f29c9aef5 >> >> 8200135: >> test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java is >> failing after JDK-8194978 >> Summary: Adjusting the expected number of exception table entries to the >> recent changes in javac. >> Reviewed-by: kvn >> >> ! test/hotspot/jtreg/ProblemList.txt >> ! >> test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java >> >> Changeset: 5fd26ab491fa >> Author: rpatil >> Date: 2018-03-26 17:33 +0530 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5fd26ab491fa >> >> 8144300: http.nonProxyHosts value having wildcard * both at end and start >> are not honored >> Summary: added validation for wildcard at start and end >> Reviewed-by: chegar, dfuchs, clanger >> Contributed-by: pallavi.sonal at oracle.com >> >> ! src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> ! test/jdk/java/net/ProxySelector/B8035158.java >> >> Changeset: 0fdb76741c56 >> Author: mcimadamore >> Date: 2018-03-28 14:08 +0100 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0fdb76741c56 >> >> 8200199: javac suggests to use var even when var is used >> Summary: local var analyzer should use synthetic var type position to >> decide if analysis is needed >> Reviewed-by: jlahoda, vromero >> >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java >> + test/langtools/tools/javac/lvti/T8200199.java >> + test/langtools/tools/javac/lvti/T8200199.out >> >> Changeset: 9925be430918 >> Author: mcimadamore >> Date: 2018-03-28 14:24 +0100 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/9925be430918 >> >> 8200355: local variable inference regression test generates classfile in >> test folder >> Summary: LVTI harness should generate files in jtreg scratch dir >> Reviewed-by: vromero >> >> ! >> test/langtools/tools/javac/lvti/harness/LocalVariableInferenceTester.java >> >> Changeset: 879cf9f18688 >> Author: rriggs >> Date: 2018-03-28 14:15 -0400 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/879cf9f18688 >> >> 8197595: Serialization javadoc should link to security best practices >> Reviewed-by: lancea, mullan, ahgross >> >> ! src/java.base/share/classes/java/io/ObjectInputFilter.java >> ! src/java.base/share/classes/java/io/ObjectInputStream.java >> ! src/java.base/share/classes/java/io/Serializable.java >> ! src/java.base/share/classes/java/io/package-info.java >> >> Changeset: bf53d82a51e5 >> Author: ihse >> Date: 2018-03-28 21:00 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/bf53d82a51e5 >> >> 8200357: Inline SoundLibraries.gmk into Lib-java.desktop.gmk >> Reviewed-by: stuefe, erikj >> >> ! make/autoconf/flags-cflags.m4 >> ! make/autoconf/platform.m4 >> ! make/autoconf/spec.gmk.in >> ! make/lib/Lib-java.desktop.gmk >> - make/lib/SoundLibraries.gmk >> >> Changeset: 396ea30afbd5 >> Author: ihse >> Date: 2018-03-28 23:56 +0200 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/396ea30afbd5 >> >> 8200178: Remove mapfiles for JDK native libraries >> Reviewed-by: erikj, alanb, mchung, prr, weijun >> >> ! make/lib/Awt2dLibraries.gmk >> ! make/lib/CoreLibraries.gmk >> ! make/lib/Lib-java.base.gmk >> ! make/lib/Lib-java.desktop.gmk >> ! make/lib/Lib-java.instrument.gmk >> ! make/lib/Lib-java.management.gmk >> ! make/lib/Lib-java.prefs.gmk >> ! make/lib/Lib-java.rmi.gmk >> ! make/lib/Lib-java.security.jgss.gmk >> ! make/lib/Lib-java.smartcardio.gmk >> ! make/lib/Lib-jdk.attach.gmk >> ! make/lib/Lib-jdk.crypto.cryptoki.gmk >> ! make/lib/Lib-jdk.crypto.ec.gmk >> ! make/lib/Lib-jdk.crypto.ucrypto.gmk >> ! make/lib/Lib-jdk.hotspot.agent.gmk >> ! make/lib/Lib-jdk.jdi.gmk >> ! make/lib/Lib-jdk.jdwp.agent.gmk >> ! make/lib/Lib-jdk.management.agent.gmk >> ! make/lib/Lib-jdk.management.gmk >> ! make/lib/Lib-jdk.net.gmk >> ! make/lib/Lib-jdk.pack.gmk >> ! make/lib/Lib-jdk.sctp.gmk >> ! make/lib/Lib-jdk.security.auth.gmk >> ! make/lib/LibCommon.gmk >> - make/mapfiles/libattach/mapfile-aix >> - make/mapfiles/libattach/mapfile-linux >> - make/mapfiles/libattach/mapfile-solaris >> - make/mapfiles/libattach/reorder-windows-x86 >> - make/mapfiles/libattach/reorder-windows-x86_64 >> - make/mapfiles/libawt/mapfile-mawt-vers >> - make/mapfiles/libawt/mapfile-vers >> - make/mapfiles/libawt/mapfile-vers-linux >> - make/mapfiles/libawt_headless/mapfile-vers >> - make/mapfiles/libawt_headless/reorder-sparc >> - make/mapfiles/libawt_headless/reorder-sparcv9 >> - make/mapfiles/libawt_headless/reorder-x86 >> - make/mapfiles/libawt_xawt/mapfile-vers >> - make/mapfiles/libdt_socket/mapfile-vers >> - make/mapfiles/libextnet/mapfile-linux >> - make/mapfiles/libextnet/mapfile-solaris >> - make/mapfiles/libfontmanager/mapfile-vers >> - make/mapfiles/libinstrument/mapfile-vers >> - make/mapfiles/libj2gss/mapfile-vers >> - make/mapfiles/libj2pcsc/mapfile-vers >> - make/mapfiles/libj2pkcs11/mapfile-vers >> - make/mapfiles/libj2ucrypto/mapfile-vers >> - make/mapfiles/libjaas/mapfile-vers >> - make/mapfiles/libjava/mapfile-vers >> - make/mapfiles/libjava/reorder-sparc >> - make/mapfiles/libjava/reorder-sparcv9 >> - make/mapfiles/libjava/reorder-x86 >> - make/mapfiles/libjawt/mapfile-vers >> - make/mapfiles/libjdwp/mapfile-vers >> - make/mapfiles/libjimage/mapfile-vers >> - make/mapfiles/libjli/mapfile-vers >> - make/mapfiles/libjpeg/mapfile-vers >> - make/mapfiles/libjpeg/reorder-sparc >> - make/mapfiles/libjpeg/reorder-sparcv9 >> - make/mapfiles/libjpeg/reorder-x86 >> - make/mapfiles/libjsdt/mapfile-vers >> - make/mapfiles/libjsig/mapfile-vers-solaris >> - make/mapfiles/liblcms/mapfile-vers >> - make/mapfiles/libmanagement/mapfile-vers >> - make/mapfiles/libmanagement_agent/mapfile-vers >> - make/mapfiles/libmanagement_ext/mapfile-vers >> - make/mapfiles/libmlib_image/mapfile-vers >> - make/mapfiles/libnet/mapfile-vers >> - make/mapfiles/libnio/mapfile-aix >> - make/mapfiles/libnio/mapfile-linux >> - make/mapfiles/libnio/mapfile-macosx >> - make/mapfiles/libnio/mapfile-solaris >> - make/mapfiles/libnio/reorder-sparc >> - make/mapfiles/libnio/reorder-sparcv9 >> - make/mapfiles/libnio/reorder-x86 >> - make/mapfiles/libprefs/mapfile-vers >> - make/mapfiles/librmi/mapfile-vers >> - make/mapfiles/libsaproc/mapfile-linux >> - make/mapfiles/libsaproc/mapfile-macosx >> - make/mapfiles/libsaproc/mapfile-solaris >> - make/mapfiles/libsctp/mapfile-vers >> - make/mapfiles/libsplashscreen/mapfile-vers >> - make/mapfiles/libsunec/mapfile-vers >> - make/mapfiles/libunpack/mapfile-vers >> - make/mapfiles/libverify/mapfile-vers >> - make/mapfiles/libverify/reorder-sparc >> - make/mapfiles/libverify/reorder-sparcv9 >> - make/mapfiles/libverify/reorder-x86 >> - make/mapfiles/libzip/mapfile-vers >> - make/mapfiles/libzip/reorder-sparc >> - make/mapfiles/libzip/reorder-sparcv9 >> - make/mapfiles/libzip/reorder-x86 >> ! src/java.base/aix/native/libjsig/jsig.c >> ! src/java.base/share/native/libjava/io_util.c >> ! src/java.base/share/native/libjava/io_util.h >> ! src/java.base/share/native/libjava/jni_util.h >> ! src/java.base/share/native/libjimage/jimage.cpp >> ! src/java.base/share/native/libjimage/jimage.hpp >> ! src/java.base/share/native/libjli/args.c >> ! src/java.base/share/native/libjli/java.c >> ! src/java.base/share/native/libjli/java.h >> ! src/java.base/share/native/libjli/jli_util.c >> ! src/java.base/share/native/libjli/jli_util.h >> ! src/java.base/share/native/libjli/manifest_info.h >> ! src/java.base/share/native/libjli/parse_manifest.c >> ! src/java.base/share/native/libnet/net_util.h >> ! src/java.base/share/native/libzip/CRC32.c >> ! src/java.base/share/native/libzip/zip_util.c >> ! src/java.base/share/native/libzip/zip_util.h >> ! src/java.base/solaris/native/libjsig/jsig.c >> ! src/java.base/unix/native/libjava/FileOutputStream_md.c >> ! src/java.base/unix/native/libjava/jni_util_md.c >> ! src/java.base/unix/native/libjli/java_md_common.c >> ! src/java.base/unix/native/libnet/net_util_md.c >> ! src/java.base/unix/native/libnio/ch/Net.c >> ! src/java.base/unix/native/libnio/ch/nio_util.h >> ! src/java.base/windows/native/libjava/io_util_md.c >> ! src/java.base/windows/native/libjava/io_util_md.h >> ! src/java.base/windows/native/libjava/jni_util_md.c >> ! src/java.base/windows/native/libjli/cmdtoargs.c >> ! src/java.base/windows/native/libjli/java_md.c >> ! src/java.base/windows/native/libnet/net_util_md.c >> ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h >> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_colors.c >> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_colors.h >> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.c >> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.h >> ! src/java.desktop/share/native/libawt/awt/image/dither.c >> ! src/java.desktop/share/native/libawt/awt/image/dither.h >> ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h >> ! src/java.desktop/share/native/libawt/java2d/SurfaceData.c >> ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h >> ! src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.c >> ! src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.h >> ! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.c >> ! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h >> ! src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c >> ! src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.h >> ! src/java.desktop/share/native/libmlib_image/mlib_image_proto.h >> ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.c >> ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h >> ! src/java.desktop/unix/native/common/awt/img_util_md.h >> ! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c >> ! src/java.desktop/unix/native/libawt/awt/initIDs.c >> ! src/java.desktop/unix/native/libsplashscreen/splashscreen_config.h >> ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> ! src/java.desktop/windows/native/libawt/windows/img_util_md.h >> ! src/java.desktop/windows/native/libsplashscreen/splashscreen_config.h >> ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCrypto.c >> ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCryptoMD.c >> ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h >> ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c >> ! src/jdk.hotspot.agent/linux/native/libsaproc/proc_service.h >> ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c >> ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c >> ! src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp >> ! src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >> ! src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >> >> Changeset: 77bff7a757a4 >> Author: martin >> Date: 2018-03-28 21:13 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/77bff7a757a4 >> >> 8200116: ConstructInflaterOutput, ConstructDeflaterInput still spamming >> test logs >> Summary: end() should always expect to be called eventually >> Reviewed-by: sherman, ulfzibis >> >> ! test/jdk/java/util/zip/ConstructDeflaterInput.java >> ! test/jdk/java/util/zip/ConstructInflaterOutput.java >> >> Changeset: d6d1c06becda >> Author: martin >> Date: 2018-03-28 21:14 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/d6d1c06becda >> >> 8200124: Various cleanups in jar/zip >> Reviewed-by: sherman, ulfzibis >> >> ! src/java.base/share/classes/java/util/jar/Manifest.java >> ! src/java.base/share/classes/java/util/zip/ZipCoder.java >> ! src/java.base/share/classes/java/util/zip/ZipFile.java >> ! src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java >> >> Changeset: e5679a6661d6 >> Author: martin >> Date: 2018-03-28 21:14 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e5679a6661d6 >> >> 8200310: Avoid charset lookup machinery in >> java.nio.charset.StandardCharsets >> Reviewed-by: sherman, ulfzibis >> >> ! src/java.base/share/classes/java/lang/StringCoding.java >> ! src/java.base/share/classes/java/nio/charset/Charset.java >> ! src/java.base/share/classes/java/nio/charset/StandardCharsets.java >> ! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java >> ! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template >> ! src/java.base/share/classes/sun/nio/cs/US_ASCII.java >> ! src/java.base/share/classes/sun/nio/cs/UTF_16.java >> ! src/java.base/share/classes/sun/nio/cs/UTF_16BE.java >> ! src/java.base/share/classes/sun/nio/cs/UTF_16LE.java >> ! src/java.base/share/classes/sun/nio/cs/UTF_8.java >> ! test/jdk/java/nio/charset/StandardCharsets/Standard.java >> >> Changeset: ae873285a39c >> Author: xiaofeya >> Date: 2018-03-28 21:57 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/ae873285a39c >> >> 8196668: revisit test SunPackageAccess and GrantedSunPackageAccess >> Reviewed-by: mchung >> >> + test/jdk/java/lang/SecurityManager/PackageAccessTest.java >> + test/jdk/java/lang/SecurityManager/empty.policy >> + test/jdk/java/lang/SecurityManager/test.policy >> >> Changeset: b85603908ae4 >> Author: erikj >> Date: 2018-03-29 08:52 -0700 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b85603908ae4 >> >> 8200409: jdk11 nightly solaris sparc build failure >> Reviewed-by: alanb, tbell >> >> ! make/lib/Lib-java.base.gmk >> + make/mapfiles/libjsig/mapfile-vers-solaris >> ! src/java.base/solaris/native/libjsig/jsig.c >> >> Changeset: a11d3a5ca20b >> Author: chegar >> Date: 2018-03-29 20:12 +0100 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a11d3a5ca20b >> >> 8200304: TwoStacksPlainDatagramSocketImpl and socket cleaner >> Reviewed-by: alanb, dfuchs, rriggs >> >> ! >> src/java.base/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java >> ! src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c >> >> Changeset: 1f9dd2360b17 >> Author: jwilhelm >> Date: 2018-03-24 01:08 +0100 >> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1f9dd2360b17 >> >> Merge >> >> ! make/autoconf/hotspot.m4 >> + src/hotspot/share/gc/cms/cmsCardTable.cpp >> - src/hotspot/share/gc/cms/parCardTableModRefBS.cpp >> ! src/hotspot/share/gc/g1/g1BarrierSet.cpp >> ! src/hotspot/share/gc/g1/g1BarrierSet.hpp >> ! src/hotspot/share/gc/g1/g1Policy.hpp >> ! src/hotspot/share/gc/parallel/psCardTable.cpp >> - src/hotspot/share/gc/shared/barrierSet.inline.hpp >> ! src/hotspot/share/gc/shared/cardTable.hpp >> + src/hotspot/share/gc/shared/cardTableBarrierSet.cpp >> + src/hotspot/share/gc/shared/cardTableBarrierSet.hpp >> + src/hotspot/share/gc/shared/cardTableBarrierSet.inline.hpp >> - src/hotspot/share/gc/shared/cardTableModRefBS.cpp >> - src/hotspot/share/gc/shared/cardTableModRefBS.hpp >> - src/hotspot/share/gc/shared/cardTableModRefBS.inline.hpp >> - src/hotspot/share/prims/jvmtiEnter.hpp From per.liden at oracle.com Mon Apr 16 19:47:54 2018 From: per.liden at oracle.com (Per Liden) Date: Mon, 16 Apr 2018 21:47:54 +0200 Subject: [aarch64-port-dev ] hg: zgc/zgc: 208 new changesets In-Reply-To: References: <201804161348.w3GDmYYO006567@aojmv0008.oracle.com> <176fb138-1528-741d-6c10-6917cdec9100@oracle.com> Message-ID: <27055e69-3f81-842f-ffa3-1b7c8500dd8f@oracle.com> Hi Stuart, On 04/16/2018 04:46 PM, Stuart Monteith wrote: > Thanks for that Per - I do appreciate being able to rebase my aarch64 > work on top of your periodic drops. Cool. As you might have noticed, the ZGC repo now includes the latest BarrierSetAssembler changes that Erik ?sterlund has been working on. This greatly simplifies the task of adding CPU-specific load barriers needed for the interpreter. > > I've gotten to the point where I am running with a slowdebug build running with: > -XX:+VerifyOops -XX:+ZVerifyForwarding -XX:+ZVerifyMarking -Xint > > The benchmark I'm running is perhaps cruel and unusual, but even with > the VM pinned to one CPU, there is an issue with verify_oop getting a > bad address (0x8). Please note that -XX:+VerifyOops has been broken in jdk/hs (and therefore also in zgc/zgc), so watch out a bit there. There's a bug for that here: https://bugs.openjdk.java.net/browse/JDK-8187078 The problem you're running into might be real, just saying don't blindly trust -XX:+VerifyOops at the moment. Would you mind uploading your current patch to cr.openjdk.java.net? I don't have a aarch64 to test/debug on, but it would be interesting to have a look anyway. cheers, Per > > BR, > Stuart > > On 16 April 2018 at 15:02, Per Liden wrote: >> FYI, this rebase brings the ZGC repo in sync with jdk/hs (as it looked mid >> Thursday last week). As jdk/hs is closing we'll be shifting over to jdk/jdk >> as upstream. >> >> cheers, >> Per >> >> On 04/16/2018 03:48 PM, per.liden at oracle.com wrote: >>> >>> Changeset: 2520a95cddf7 >>> Author: stefank >>> Date: 2018-03-26 17:01 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2520a95cddf7 >>> >>> 8200292: Move PushAndMarkVerifyClosure::do_oop_work to >>> concurrentMarkSweepGeneration.cpp >>> Reviewed-by: tschatzl, sjohanss >>> >>> ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp >>> ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.hpp >>> >>> Changeset: 64f9ebc85e67 >>> Author: tschatzl >>> Date: 2018-03-28 16:39 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/64f9ebc85e67 >>> >>> 8197573: Remove concurrent cleanup and secondary free list handling >>> Summary: Remove secondary free list and all associated functionality, >>> moving the cleanup work into the Cleanup pause instead. >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/concurrentMarkThread.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >>> ! src/hotspot/share/gc/g1/g1CollectorState.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp >>> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.hpp >>> ! src/hotspot/share/gc/g1/g1RemSet.cpp >>> ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp >>> ! src/hotspot/share/gc/g1/g1_globals.hpp >>> ! src/hotspot/share/gc/g1/heapRegion.cpp >>> ! src/hotspot/share/gc/g1/heapRegion.hpp >>> ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp >>> ! src/hotspot/share/gc/g1/heapRegionSet.cpp >>> ! src/hotspot/share/gc/g1/heapRegionSet.hpp >>> ! src/hotspot/share/runtime/mutexLocker.cpp >>> ! src/hotspot/share/runtime/mutexLocker.hpp >>> ! >>> test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java >>> ! >>> test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java >>> >>> Changeset: 29ad59abc54a >>> Author: tschatzl >>> Date: 2018-03-28 16:39 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/29ad59abc54a >>> >>> 8197928: Only enqueue deferred cards with references into regions that >>> have a tracked remembered set during GC >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp >>> >>> Changeset: df9dcfff6628 >>> Author: tschatzl >>> Date: 2018-03-28 16:39 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/df9dcfff6628 >>> >>> 8197932: Better split work in rebuild remembered sets phase >>> Summary: Let threads rebuilding remembered sets yield after every >>> G1RebuildRemSetChunkSize (default: 256kB) sized memory area to improve TTSP. >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp >>> ! src/hotspot/share/gc/g1/g1RemSet.cpp >>> ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp >>> ! src/hotspot/share/gc/g1/g1_globals.hpp >>> >>> Changeset: e79bbf1635da >>> Author: tschatzl >>> Date: 2018-03-28 16:39 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e79bbf1635da >>> >>> 8199326: Remove G1 gc time stamp logic >>> Summary: G1 gc time stamp logic is unused completely after JDK-8180415, so >>> removing it. >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/g1Allocator.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp >>> ! src/hotspot/share/gc/g1/heapRegion.cpp >>> ! src/hotspot/share/gc/g1/heapRegion.hpp >>> >>> Changeset: 6d5bd76650df >>> Author: dcubed >>> Date: 2018-03-28 12:04 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/6d5bd76650df >>> >>> 8199813: SIGSEGV in ThreadsList::includes() >>> Summary: ThreadsListHandles cannot be used by JavaThreads that are not on >>> the Threads list. >>> Reviewed-by: eosterlund, gthornbr, dholmes, rehn >>> >>> ! src/hotspot/os/linux/os_linux.cpp >>> ! src/hotspot/share/runtime/thread.cpp >>> ! src/hotspot/share/runtime/threadSMR.cpp >>> ! src/hotspot/share/runtime/vm_operations.cpp >>> ! src/hotspot/share/runtime/vm_operations.hpp >>> >>> Changeset: ab0f93ba0507 >>> Author: amenkov >>> Date: 2018-03-28 12:10 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/ab0f93ba0507 >>> >>> 8198393: Instrumentation.retransformClasses() throws NullPointerException >>> when handling a zero-length array >>> Reviewed-by: sspitsyn, cjplummer >>> >>> ! >>> src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >>> + >>> test/hotspot/jtreg/serviceability/jvmti/RetransformClassesZeroLength.java >>> >>> Changeset: 5af65ee8b77e >>> Author: lmesnik >>> Date: 2018-03-28 13:38 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5af65ee8b77e >>> >>> 8200091: [TESTBUG] Update jittester for jdk11 >>> Reviewed-by: iignatyev >>> >>> ! test/hotspot/jtreg/testlibrary/jittester/Makefile >>> >>> Changeset: 4f7cfd7fdd50 >>> Author: lmesnik >>> Date: 2018-03-28 13:25 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/4f7cfd7fdd50 >>> >>> 8200187: Exclude 3 long-running tests from tier1 >>> Reviewed-by: dholmes, cjplummer >>> >>> ! test/hotspot/jtreg/TEST.groups >>> >>> Changeset: dd76fcbda95f >>> Author: kvn >>> Date: 2018-03-28 17:20 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/dd76fcbda95f >>> >>> 8200383: Can't build on SPARC Hotspot with code which use math functions >>> Summary: remove old hack which supports Solaris 8 and 9 >>> Reviewed-by: erikj, ihse >>> >>> ! make/autoconf/libraries.m4 >>> ! make/lib/Awt2dLibraries.gmk >>> >>> Changeset: 2ad3212a7dd9 >>> Author: redestad >>> Date: 2018-03-29 10:38 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2ad3212a7dd9 >>> >>> 8200238: Reduce number of exceptions created when calling >>> MemberName$Factory::resolveOrNull >>> Reviewed-by: lfoltan, acorn, dholmes >>> >>> ! src/hotspot/share/classfile/systemDictionary.cpp >>> ! src/hotspot/share/prims/methodHandles.cpp >>> ! src/hotspot/share/prims/methodHandles.hpp >>> ! src/java.base/share/classes/java/lang/invoke/MemberName.java >>> ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java >>> >>> Changeset: 7bad9c9efdf3 >>> Author: shade >>> Date: 2018-03-29 12:56 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7bad9c9efdf3 >>> >>> 8200423: Non-PCH build for x86_32 fails >>> Reviewed-by: rkennke, stuefe >>> >>> ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp >>> >>> Changeset: a3453bbd5418 >>> Author: tschatzl >>> Date: 2018-03-29 14:07 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a3453bbd5418 >>> >>> 8199742: Clean up state flags in G1CollectorState >>> Summary: Remove, merge and update naming of flags in G1CollectorState >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/g1Allocator.cpp >>> ! src/hotspot/share/gc/g1/g1Analytics.cpp >>> ! src/hotspot/share/gc/g1/g1Analytics.hpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp >>> ! src/hotspot/share/gc/g1/g1CollectionSet.cpp >>> ! src/hotspot/share/gc/g1/g1CollectorState.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1EvacFailure.cpp >>> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.hpp >>> ! src/hotspot/share/gc/g1/g1RootClosures.cpp >>> ! src/hotspot/share/gc/g1/g1RootProcessor.cpp >>> ! src/hotspot/share/gc/g1/g1YCTypes.hpp >>> ! src/hotspot/share/gc/g1/heapRegion.cpp >>> >>> Changeset: 50a01910e00a >>> Author: tschatzl >>> Date: 2018-03-29 14:08 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/50a01910e00a >>> >>> 8151171: Bring g1ConcurrentMark files up to current coding conventions >>> Summary: Improve method naming, bracketing, use of _g1h member and general >>> cleanup. >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/concurrentMarkThread.cpp >>> ! src/hotspot/share/gc/g1/concurrentMarkThread.hpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.hpp >>> ! src/hotspot/share/gc/g1/g1OopClosures.hpp >>> >>> Changeset: 2bf8f2fc0710 >>> Author: simonis >>> Date: 2018-03-29 14:50 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2bf8f2fc0710 >>> >>> 8200360: MeetIncompatibleInterfaceArrays fails with >>> "MeetIncompatibleInterfaceArrays0ASM.run() must be compiled at tier 0 !" >>> Reviewed-by: kvn, thartmann >>> >>> ! >>> test/hotspot/jtreg/compiler/types/TestMeetIncompatibleInterfaceArrays.java >>> >>> Changeset: 24aca5861b91 >>> Author: redestad >>> Date: 2018-03-29 15:05 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/24aca5861b91 >>> >>> 8200424: Windows build fails due to implicit jboolean to bool conversion >>> Reviewed-by: shade, hseigel >>> >>> ! src/hotspot/share/prims/methodHandles.cpp >>> >>> Changeset: 5a757c0326c7 >>> Author: tschatzl >>> Date: 2018-03-29 17:15 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5a757c0326c7 >>> >>> 8200362: G1Mux2Closure should disable implicit oop verification >>> Summary: To avoid the implicit oop verification provided by OopClosure and >>> oop_iterate_no_header, let G1 verification closures inherit from >>> ExtendedOopClosures and disable this verification. >>> Reviewed-by: stefank, sjohanss >>> >>> ! src/hotspot/share/gc/g1/heapRegion.cpp >>> >>> Changeset: 7f5fca094057 >>> Author: kvn >>> Date: 2018-03-29 09:52 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7f5fca094057 >>> >>> 8200391: clean up test/hotspot/jtreg/ProblemList.txt (compiler related) >>> Reviewed-by: mseledtsov >>> >>> ! test/hotspot/jtreg/ProblemList-graal.txt >>> >>> Changeset: 17c6ab93710e >>> Author: dstewart >>> Date: 2018-03-29 16:07 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/17c6ab93710e >>> >>> 8200251: AArch64::CPUFeature out of sync with VM_Version::Feature_Flag >>> Summary: Added enums to CPUFeature to be in sync with >>> VM_Version::Feature_Flag >>> Reviewed-by: kvn, aph, shade >>> >>> ! >>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64.java >>> >>> Changeset: c42db4d81e33 >>> Author: lucy >>> Date: 2018-03-29 14:53 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/c42db4d81e33 >>> >>> 8200366: SIGSEGV in CodeHeapState::print_names() >>> Summary: Temporary removed the failing function in diagnostic command >>> until investigation is complete. Added checks to validate code blobs. >>> Reviewed-by: kvn, thartmann >>> >>> ! src/hotspot/share/code/codeHeapState.cpp >>> ! src/hotspot/share/services/diagnosticCommand.cpp >>> >>> Changeset: 1e11c8a238f7 >>> Author: iklam >>> Date: 2018-03-29 20:15 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1e11c8a238f7 >>> >>> 8183238: Obsolete CheckEndorsedAndExtDirs and remove checks for >>> lib/endorsed and lib/ext >>> Reviewed-by: dholmes, mchung, alanb >>> >>> ! src/bsd/doc/man/java.1 >>> ! src/hotspot/share/runtime/arguments.cpp >>> ! src/hotspot/share/runtime/globals.hpp >>> ! src/linux/doc/man/java.1 >>> ! src/solaris/doc/sun/man/man1/java.1 >>> >>> Changeset: a74836b05c28 >>> Author: ccheung >>> Date: 2018-03-29 21:48 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a74836b05c28 >>> >>> 8200078: [Graal] runtime/appcds/GraalWithLimitedMetaspace.java crashes in >>> visit_all_interfaces >>> Summary: stop CDS dumping right away when an OOM due to insufficient >>> metaspace is encountered >>> Reviewed-by: iklam, mseledtsov >>> >>> ! src/hotspot/share/memory/metaspace.cpp >>> ! test/hotspot/jtreg/runtime/SharedArchiveFile/MaxMetaspaceSize.java >>> ! test/hotspot/jtreg/runtime/appcds/GraalWithLimitedMetaspace.java >>> >>> Changeset: a569cb4425f3 >>> Author: stuefe >>> Date: 2018-03-30 06:31 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a569cb4425f3 >>> >>> 8191101: Show register content in hs-err file on assert >>> Reviewed-by: adinn, clanger, simonis >>> >>> ! src/hotspot/os/posix/vmError_posix.cpp >>> ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp >>> ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp >>> ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp >>> ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp >>> ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp >>> ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp >>> ! src/hotspot/share/runtime/arguments.cpp >>> ! src/hotspot/share/runtime/globals.hpp >>> ! src/hotspot/share/runtime/thread.cpp >>> ! src/hotspot/share/utilities/debug.cpp >>> ! src/hotspot/share/utilities/debug.hpp >>> ! src/hotspot/share/utilities/vmError.cpp >>> ! src/hotspot/share/utilities/vmError.hpp >>> + test/hotspot/jtreg/runtime/ErrorHandling/ShowRegistersOnAssertTest.java >>> >>> Changeset: 16f53c9c7493 >>> Author: kvn >>> Date: 2018-03-30 07:47 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/16f53c9c7493 >>> >>> 8200461: MeetIncompatibleInterfaceArrays test fails with -Xcomp >>> Summary: Add requires to run test only in Xmixed mode. >>> Reviewed-by: simonis >>> >>> ! >>> test/hotspot/jtreg/compiler/types/TestMeetIncompatibleInterfaceArrays.java >>> >>> Changeset: d6893a76c554 >>> Author: poonam >>> Date: 2018-03-30 18:46 +0000 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/d6893a76c554 >>> >>> 8199406: Performance drop with Java JDK 1.8.0_162-b32 >>> Summary: Improve the nmethod unloading times by optimizing the search for >>> an itable stub in VtableStubs array >>> Reviewed-by: kvn, coleenp, tschatzl >>> >>> ! src/hotspot/share/code/codeBlob.cpp >>> ! src/hotspot/share/code/codeBlob.hpp >>> ! src/hotspot/share/code/compiledIC.cpp >>> ! src/hotspot/share/code/vtableStubs.cpp >>> ! src/hotspot/share/code/vtableStubs.hpp >>> ! src/hotspot/share/oops/compiledICHolder.cpp >>> ! src/hotspot/share/oops/compiledICHolder.hpp >>> >>> Changeset: be608cad0b2a >>> Author: kbarrett >>> Date: 2018-03-30 21:57 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/be608cad0b2a >>> >>> 8195972: Refactor oops in JNI to use the Access API >>> Summary: Use Access API in JNIHandles >>> Reviewed-by: coleenp, eosterlund >>> >>> ! src/hotspot/share/runtime/jniHandles.cpp >>> ! src/hotspot/share/runtime/jniHandles.hpp >>> ! src/hotspot/share/runtime/jniHandles.inline.hpp >>> >>> Changeset: 45071514f87a >>> Author: shade >>> Date: 2018-04-03 10:27 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/45071514f87a >>> >>> 8200438: Non-PCH x86_32 build failure: err_msg is not defined >>> Reviewed-by: stuefe, zgu, stefank >>> >>> ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp >>> >>> Changeset: 8237a91c1cca >>> Author: rkennke >>> Date: 2018-04-03 13:15 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/8237a91c1cca >>> >>> 8199781: Don't use naked == for comparing oops >>> Reviewed-by: coleenp, eosterlund, jrose >>> >>> ! src/hotspot/share/ci/ciEnv.cpp >>> ! src/hotspot/share/ci/ciObjectFactory.cpp >>> ! src/hotspot/share/classfile/classLoaderData.cpp >>> ! src/hotspot/share/classfile/dictionary.cpp >>> ! src/hotspot/share/classfile/javaClasses.cpp >>> ! src/hotspot/share/classfile/protectionDomainCache.cpp >>> ! src/hotspot/share/classfile/systemDictionary.cpp >>> ! src/hotspot/share/code/dependencies.cpp >>> ! src/hotspot/share/gc/shared/barrierSet.hpp >>> ! src/hotspot/share/interpreter/bytecodeInterpreter.cpp >>> ! src/hotspot/share/interpreter/interpreterRuntime.cpp >>> ! src/hotspot/share/memory/universe.cpp >>> + src/hotspot/share/oops/access.cpp >>> ! src/hotspot/share/oops/access.hpp >>> ! src/hotspot/share/oops/access.inline.hpp >>> ! src/hotspot/share/oops/accessBackend.hpp >>> + src/hotspot/share/oops/accessDecorators.hpp >>> ! src/hotspot/share/oops/constantPool.cpp >>> ! src/hotspot/share/oops/instanceKlass.cpp >>> ! src/hotspot/share/oops/klassVtable.cpp >>> ! src/hotspot/share/oops/objArrayKlass.cpp >>> ! src/hotspot/share/oops/oop.hpp >>> ! src/hotspot/share/prims/jni.cpp >>> ! src/hotspot/share/prims/jvm.cpp >>> ! src/hotspot/share/prims/methodHandles.cpp >>> ! src/hotspot/share/prims/stackwalk.cpp >>> ! src/hotspot/share/prims/unsafe.cpp >>> ! src/hotspot/share/runtime/biasedLocking.cpp >>> ! src/hotspot/share/runtime/handles.hpp >>> ! src/hotspot/share/runtime/reflection.cpp >>> ! src/hotspot/share/runtime/synchronizer.cpp >>> ! src/hotspot/share/services/memoryManager.hpp >>> ! src/hotspot/share/services/memoryPool.hpp >>> ! src/hotspot/share/services/threadService.cpp >>> ! src/hotspot/share/utilities/exceptions.cpp >>> ! src/hotspot/share/utilities/growableArray.hpp >>> >>> Changeset: 0ed1370f52bb >>> Author: lkorinth >>> Date: 2018-04-03 12:05 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0ed1370f52bb >>> >>> 8200371: In g1, rename ConcurrentMarkThread to G1ConcurrentMarkThread >>> Reviewed-by: tschatzl, sangheki >>> >>> - src/hotspot/share/gc/g1/concurrentMarkThread.cpp >>> - src/hotspot/share/gc/g1/concurrentMarkThread.hpp >>> - src/hotspot/share/gc/g1/concurrentMarkThread.inline.hpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp >>> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp >>> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp >>> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.cpp >>> ! src/hotspot/share/gc/g1/vm_operations_g1.cpp >>> ! src/hotspot/share/prims/whitebox.cpp >>> ! src/hotspot/share/runtime/thread.cpp >>> >>> Changeset: 89a886b7a9cf >>> Author: redestad >>> Date: 2018-04-03 12:55 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/89a886b7a9cf >>> >>> 8199717: Avoid calculating primordial thread stack bounds on VM startup >>> Reviewed-by: dholmes, rehn, stuefe >>> >>> ! src/hotspot/os/linux/os_linux.cpp >>> >>> Changeset: a3fed4b041ac >>> Author: rkennke >>> Date: 2018-04-03 17:36 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a3fed4b041ac >>> >>> 8199780: SetMemory0 and CopyMemory0 in unsafe.cpp need to resolve their >>> operands >>> Reviewed-by: shade, zgu, eosterlund >>> >>> ! src/hotspot/share/prims/unsafe.cpp >>> >>> Changeset: 3614cbddd005 >>> Author: mseledtsov >>> Date: 2018-04-03 08:56 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/3614cbddd005 >>> >>> 8200126: [TESTBUG] Open source VM runtime signal tests >>> Summary: Open sourced the signal tests, updated make files and test groups >>> accordingly >>> Reviewed-by: dholmes, ctornqvi, ihse >>> >>> ! make/test/JtregNativeHotspot.gmk >>> ! test/hotspot/jtreg/TEST.groups >>> + test/hotspot/jtreg/runtime/signal/README >>> + test/hotspot/jtreg/runtime/signal/SigTestDriver.java >>> + test/hotspot/jtreg/runtime/signal/TestSigalrm.java >>> + test/hotspot/jtreg/runtime/signal/TestSigbus.java >>> + test/hotspot/jtreg/runtime/signal/TestSigcld.java >>> + test/hotspot/jtreg/runtime/signal/TestSigcont.java >>> + test/hotspot/jtreg/runtime/signal/TestSigemt.java >>> + test/hotspot/jtreg/runtime/signal/TestSigfpe.java >>> + test/hotspot/jtreg/runtime/signal/TestSigfreeze.java >>> + test/hotspot/jtreg/runtime/signal/TestSighup.java >>> + test/hotspot/jtreg/runtime/signal/TestSigill.java >>> + test/hotspot/jtreg/runtime/signal/TestSigint.java >>> + test/hotspot/jtreg/runtime/signal/TestSigiot.java >>> + test/hotspot/jtreg/runtime/signal/TestSiglost.java >>> + test/hotspot/jtreg/runtime/signal/TestSiglwp.java >>> + test/hotspot/jtreg/runtime/signal/TestSigpipe.java >>> + test/hotspot/jtreg/runtime/signal/TestSigpoll.java >>> + test/hotspot/jtreg/runtime/signal/TestSigprof.java >>> + test/hotspot/jtreg/runtime/signal/TestSigpwr.java >>> + test/hotspot/jtreg/runtime/signal/TestSigquit.java >>> + test/hotspot/jtreg/runtime/signal/TestSigsegv.java >>> + test/hotspot/jtreg/runtime/signal/TestSigstop.java >>> + test/hotspot/jtreg/runtime/signal/TestSigsys.java >>> + test/hotspot/jtreg/runtime/signal/TestSigterm.java >>> + test/hotspot/jtreg/runtime/signal/TestSigthaw.java >>> + test/hotspot/jtreg/runtime/signal/TestSigtrap.java >>> + test/hotspot/jtreg/runtime/signal/TestSigtstp.java >>> + test/hotspot/jtreg/runtime/signal/TestSigttin.java >>> + test/hotspot/jtreg/runtime/signal/TestSigttou.java >>> + test/hotspot/jtreg/runtime/signal/TestSigurg.java >>> + test/hotspot/jtreg/runtime/signal/TestSigusr1.java >>> + test/hotspot/jtreg/runtime/signal/TestSigusr2.java >>> + test/hotspot/jtreg/runtime/signal/TestSigvtalrm.java >>> + test/hotspot/jtreg/runtime/signal/TestSigwinch.java >>> + test/hotspot/jtreg/runtime/signal/TestSigxcpu.java >>> + test/hotspot/jtreg/runtime/signal/TestSigxfsz.java >>> + test/hotspot/jtreg/runtime/signal/TestSigxres.java >>> + test/hotspot/jtreg/runtime/signal/exesigtest.c >>> >>> Changeset: 0ab2411f270d >>> Author: rwestberg >>> Date: 2018-03-28 15:30 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0ab2411f270d >>> >>> 8199619: Building HotSpot on Windows should define NOMINMAX >>> Reviewed-by: erikj, kbarrett, ihse >>> >>> ! make/autoconf/flags-cflags.m4 >>> >>> Changeset: 9a04cc89dde0 >>> Author: tschatzl >>> Date: 2018-04-04 11:21 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/9a04cc89dde0 >>> >>> 8200234: Cleanup Remark and Cleanup pause code >>> Summary: Remove redundant methods, factor out verification code and >>> simplify code in Remark and Cleanup pause code. >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/g1CollectorState.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.cpp >>> ! src/hotspot/share/gc/g1/heapRegion.inline.hpp >>> >>> Changeset: 8bad6c08a732 >>> Author: tschatzl >>> Date: 2018-04-04 11:21 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/8bad6c08a732 >>> >>> 8200255: Remove G1CMTask::_concurrent >>> Reviewed-by: sangheki, sjohanss >>> >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> >>> Changeset: 55f8f5635ef7 >>> Author: tschatzl >>> Date: 2018-04-04 11:21 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/55f8f5635ef7 >>> >>> 8200074: Remove G1ConcurrentMark::_concurrent_marking_in_progress >>> Reviewed-by: sjohanss, sangheki >>> >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> >>> Changeset: 2fef34f04314 >>> Author: ehelin >>> Date: 2018-04-04 10:12 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/2fef34f04314 >>> >>> 8200626: Restore history for g1ConcurrentMarkThread.* >>> Reviewed-by: shade, sjohanss >>> >>> - src/hotspot/share/gc/g1/concurrentMarkThread.cpp >>> - src/hotspot/share/gc/g1/concurrentMarkThread.hpp >>> - src/hotspot/share/gc/g1/concurrentMarkThread.inline.hpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp >>> ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp >>> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp >>> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp >>> + src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp >>> ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp >>> ! src/hotspot/share/gc/g1/g1Policy.cpp >>> ! src/hotspot/share/gc/g1/vm_operations_g1.cpp >>> ! src/hotspot/share/prims/whitebox.cpp >>> ! src/hotspot/share/runtime/thread.cpp >>> >>> Changeset: 8263950638ed >>> Author: ehelin >>> Date: 2018-04-04 11:25 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/8263950638ed >>> >>> Merge >>> >>> ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp >>> ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp >>> >>> Changeset: 3569b528972e >>> Author: pliden >>> Date: 2018-04-04 11:59 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/3569b528972e >>> >>> 8200429: Adjust object pinning interface on CollectedHeap >>> Reviewed-by: dholmes, rkennke >>> >>> ! src/hotspot/share/gc/shared/collectedHeap.cpp >>> ! src/hotspot/share/gc/shared/collectedHeap.hpp >>> ! src/hotspot/share/prims/jni.cpp >>> >>> Changeset: 1a1a69219637 >>> Author: pliden >>> Date: 2018-04-04 11:59 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1a1a69219637 >>> >>> 8200607: Add missing include dependency in bitMap.hpp >>> Reviewed-by: shade, stefank >>> >>> ! src/hotspot/share/utilities/bitMap.hpp >>> >>> Changeset: 015af70b9a1d >>> Author: shade >>> Date: 2018-04-04 12:06 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/015af70b9a1d >>> >>> 8200608: Build failures after JDK-8191101 (Show register content in hs-err >>> file on assert) >>> Reviewed-by: dholmes, tschatzl >>> >>> ! src/hotspot/share/utilities/debug.cpp >>> >>> Changeset: f1d2b6c0693b >>> Author: tschatzl >>> Date: 2018-04-04 14:51 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/f1d2b6c0693b >>> >>> 8200305: Update gc,liveness output with remset state after rebuild remset >>> concurrently changes >>> Reviewed-by: sjohanss, sangheki >>> >>> ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp >>> ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp >>> ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp >>> >>> Changeset: 46b2f783116c >>> Author: dstewart >>> Date: 2018-03-30 13:39 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/46b2f783116c >>> >>> 8200524: AArch64: CPUFeature and Flag enums are not passed through JVMCI >>> Summary: AArch64 VM_Version::features and flags are correspondingly set in >>> CPUFeature and Flags >>> Reviewed-by: kvn, fyang >>> >>> ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp >>> ! >>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.aarch64/src/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotJVMCIBackendFactory.java >>> ! >>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.aarch64/src/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotVMConfig.java >>> >>> Changeset: c39f20946b37 >>> Author: dpochepk >>> Date: 2018-04-04 23:02 +0300 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/c39f20946b37 >>> >>> 8200627: aarch32 - Broken build after JDK-8198949 >>> Reviewed-by: shade, eosterlund >>> Contributed-by: boris.ulasevich at bell-sw.com >>> >>> ! src/hotspot/cpu/arm/gc/g1/g1BarrierSetAssembler_arm.hpp >>> ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.hpp >>> ! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp >>> ! src/hotspot/cpu/arm/gc/shared/modRefBarrierSetAssembler_arm.hpp >>> ! src/hotspot/cpu/arm/stubGenerator_arm.cpp >>> >>> Changeset: e862d3c78123 >>> Author: dpochepk >>> Date: 2018-04-04 23:05 +0300 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e862d3c78123 >>> >>> 8200628: aarch32 - Broken build after JDK-8199809 >>> Reviewed-by: shade, coleenp >>> Contributed-by: boris.ulasevich at bell-sw.com >>> >>> ! src/hotspot/cpu/arm/interpreterRT_arm.cpp >>> >>> Changeset: 0bb0c2f27ca9 >>> Author: kbarrett >>> Date: 2018-04-04 18:19 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0bb0c2f27ca9 >>> >>> 8200630: Globally suppress Visual Studio warning C4351 >>> Summary: Globally suppress warning, remove sole instance of local >>> suppression. >>> Reviewed-by: gtriantafill, tschatzl >>> >>> ! src/hotspot/share/gc/shared/oopStorage.cpp >>> ! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp >>> >>> Changeset: a1a7456dd8b9 >>> Author: hseigel >>> Date: 2018-04-05 13:19 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a1a7456dd8b9 >>> >>> 8200261: Regression with JVM anonymous class >>> Summary: Restore resolved anonymous class when creating a new constantpool >>> because of overpass methods >>> Reviewed-by: coleenp, lfoltan >>> >>> ! src/hotspot/share/classfile/classFileParser.cpp >>> ! src/hotspot/share/classfile/defaultMethods.cpp >>> ! src/hotspot/share/oops/instanceKlass.hpp >>> + test/hotspot/jtreg/runtime/defineAnonClass/UnsafeDefMeths.java >>> >>> Changeset: fa26e7c6efb7 >>> Author: gadams >>> Date: 2018-04-05 11:18 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/fa26e7c6efb7 >>> >>> 8199782: Fix compilation warnings detected by Solaris Developer Studio >>> 12.6 >>> Reviewed-by: sspitsyn, dholmes, ihse >>> >>> ! make/hotspot/lib/CompileJvm.gmk >>> ! src/java.base/solaris/native/libjvm_db/libjvm_db.c >>> ! test/fmw/gtest/src/gtest.cc >>> ! test/hotspot/jtreg/runtime/libadimalloc.solaris.sparc/liboverflow.c >>> >>> Changeset: 0ee57b9b376c >>> Author: chegar >>> Date: 2018-03-23 21:39 +0000 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0ee57b9b376c >>> >>> 8200181: Remove superflous non-IPv4 code from >>> Java_java_net_TwoStacksPlainSocketImpl_socketListen >>> Reviewed-by: alanb >>> >>> ! src/java.base/windows/native/libnet/TwoStacksPlainSocketImpl.c >>> >>> Changeset: 1f14faf358fb >>> Author: bpb >>> Date: 2018-03-23 15:05 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1f14faf358fb >>> >>> 8180410: ByteArrayOutputStream should not throw IOExceptions >>> Summary: Add ByteArrayOutputStream.writeBytes() >>> Reviewed-by: rriggs, smarks >>> >>> ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java >>> + test/jdk/java/io/ByteArrayOutputStream/Write.java >>> - test/jdk/java/io/ByteArrayOutputStream/WriteBounds.java >>> >>> Changeset: 56a5f899e882 >>> Author: jjg >>> Date: 2018-03-23 17:28 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/56a5f899e882 >>> >>> 8199902: {@docRoot} references need to be updated to reflect new >>> module/package structure >>> Reviewed-by: ksrini >>> >>> ! src/jdk.compiler/share/classes/com/sun/source/doctree/package-info.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/package-info.java >>> ! src/jdk.javadoc/share/classes/com/sun/javadoc/ClassDoc.java >>> ! src/jdk.javadoc/share/classes/com/sun/javadoc/Doc.java >>> ! src/jdk.javadoc/share/classes/com/sun/javadoc/PackageDoc.java >>> ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java >>> ! src/jdk.javadoc/share/classes/module-info.java >>> >>> Changeset: f14852315495 >>> Author: shinyafox >>> Date: 2018-03-24 14:43 +0900 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/f14852315495 >>> >>> 8199762: JShell API: Failed to detect override when snippet to be >>> overridden has been changed before >>> Reviewed-by: rfield >>> >>> ! src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java >>> ! src/jdk.jshell/share/classes/jdk/jshell/Unit.java >>> ! test/langtools/jdk/jshell/MethodsTest.java >>> >>> Changeset: 1d3139252c1c >>> Author: alanb >>> Date: 2018-03-24 08:49 +0000 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1d3139252c1c >>> >>> 8200179: (se) More Selector cleanup >>> Reviewed-by: bpb >>> >>> ! make/CompileJavaModules.gmk >>> ! make/mapfiles/libnio/mapfile-linux >>> ! make/mapfiles/libnio/mapfile-macosx >>> ! make/mapfiles/libnio/mapfile-solaris >>> - src/java.base/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java >>> - src/java.base/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java >>> - src/java.base/share/classes/sun/nio/ch/PollSelectorProvider.java >>> ! src/java.base/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java >>> ! src/java.base/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java >>> ! src/java.base/solaris/classes/sun/nio/ch/EventPortSelectorImpl.java >>> - src/java.base/solaris/classes/sun/nio/ch/EventPortWrapper.java >>> - src/java.base/unix/classes/sun/nio/ch/PollArrayWrapper.java >>> ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java >>> + src/java.base/unix/classes/sun/nio/ch/PollSelectorProvider.java >>> ! src/java.base/unix/native/libnio/ch/Net.c >>> - src/java.base/unix/native/libnio/ch/PollArrayWrapper.c >>> + src/java.base/unix/native/libnio/ch/PollSelectorImpl.c >>> ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java >>> ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java >>> ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java >>> >>> Changeset: 5bfe30bb50a2 >>> Author: dholmes >>> Date: 2018-03-26 00:33 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5bfe30bb50a2 >>> >>> 8200213: Configure broken on MIPS >>> Reviewed-by: erikj, stuefe, dholmes, ihse >>> Contributed-by: Ao Qi >>> >>> ! make/autoconf/flags.m4 >>> >>> Changeset: b39bc2eb8325 >>> Author: jlahoda >>> Date: 2018-03-26 11:42 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b39bc2eb8325 >>> >>> 8196519: Incomplete classpath causes infinite recursion in >>> Resolve.isAccessible >>> Summary: ErrorType.getEnclosingType returns noType rather than self. >>> Reviewed-by: mcimadamore, cushon >>> >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java >>> + >>> test/langtools/tools/javac/processing/model/MissingClassRecursiveAccessible.java >>> >>> Changeset: 7b8696b3b972 >>> Author: shade >>> Date: 2018-03-26 15:09 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7b8696b3b972 >>> >>> 8200118: [TESTBUG] String concat tests should test toString() application >>> order >>> Reviewed-by: psandoz, redestad >>> >>> + test/jdk/java/lang/String/concat/ImplicitStringConcatOrder.java >>> >>> Changeset: 458c790b6995 >>> Author: sundar >>> Date: 2018-03-26 19:27 +0530 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/458c790b6995 >>> >>> 8200215: 17th loop of "let foo = ''"; throws ReferenceError >>> Reviewed-by: jlaskey, attila, hannesw >>> >>> ! >>> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java >>> + test/nashorn/script/trusted/JDK-8200215.js >>> >>> Changeset: b64cd942ac7a >>> Author: shade >>> Date: 2018-03-26 20:20 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b64cd942ac7a >>> >>> 8200241: [TESTBUG] java/lang/String/concat/ tests should not force >>> source/target = 9 anymore >>> Reviewed-by: redestad, psandoz >>> >>> ! test/jdk/java/lang/String/concat/CompactStringsInitialCoder.java >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcat.java >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcatArgCount.java >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcatMany.java >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcatManyLongs.java >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcatOrder.java >>> ! >>> test/jdk/java/lang/String/concat/ImplicitStringConcatShapes-head.template >>> ! test/jdk/java/lang/String/concat/ImplicitStringConcatShapes.java >>> >>> Changeset: fd608d605e2f >>> Author: ihse >>> Date: 2018-03-26 20:44 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/fd608d605e2f >>> >>> 8200229: Simplify building of libjsig >>> Reviewed-by: erikj >>> >>> ! make/Main.gmk >>> - make/hotspot/lib/CompileLibjsig.gmk >>> ! make/lib/Lib-java.base.gmk >>> >>> Changeset: 4269e701448e >>> Author: serb >>> Date: 2018-03-26 16:09 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/4269e701448e >>> >>> 8200198: javah man pages were not removed by JDK-8191054 >>> Reviewed-by: erikj, alanb >>> >>> - src/bsd/doc/man/ja/javah.1 >>> ! src/bsd/doc/man/java.1 >>> ! src/bsd/doc/man/javac.1 >>> ! src/bsd/doc/man/javadoc.1 >>> - src/bsd/doc/man/javah.1 >>> ! src/bsd/doc/man/javap.1 >>> ! src/bsd/doc/man/jdb.1 >>> ! src/linux/doc/man/ja/java.1 >>> ! src/linux/doc/man/ja/javac.1 >>> ! src/linux/doc/man/ja/javadoc.1 >>> - src/linux/doc/man/ja/javah.1 >>> ! src/linux/doc/man/ja/javap.1 >>> ! src/linux/doc/man/ja/jdb.1 >>> ! src/linux/doc/man/java.1 >>> ! src/linux/doc/man/javac.1 >>> ! src/linux/doc/man/javadoc.1 >>> - src/linux/doc/man/javah.1 >>> ! src/linux/doc/man/javap.1 >>> ! src/linux/doc/man/jdb.1 >>> ! src/solaris/doc/sun/man/man1/ja/java.1 >>> ! src/solaris/doc/sun/man/man1/ja/javac.1 >>> ! src/solaris/doc/sun/man/man1/ja/javadoc.1 >>> - src/solaris/doc/sun/man/man1/ja/javah.1 >>> ! src/solaris/doc/sun/man/man1/ja/javap.1 >>> ! src/solaris/doc/sun/man/man1/ja/jdb.1 >>> ! src/solaris/doc/sun/man/man1/java.1 >>> ! src/solaris/doc/sun/man/man1/javac.1 >>> ! src/solaris/doc/sun/man/man1/javadoc.1 >>> - src/solaris/doc/sun/man/man1/javah.1 >>> ! src/solaris/doc/sun/man/man1/javap.1 >>> ! src/solaris/doc/sun/man/man1/jdb.1 >>> >>> Changeset: e9cb414f94eb >>> Author: erikj >>> Date: 2018-03-26 16:24 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e9cb414f94eb >>> >>> 8198652: Stop linking with -base:0x8000000 on Windows >>> Reviewed-by: tbell, ihse, stuefe >>> >>> ! make/autoconf/flags-ldflags.m4 >>> >>> Changeset: 7f3986bad197 >>> Author: igerasim >>> Date: 2018-03-26 17:30 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/7f3986bad197 >>> >>> 8199843: Optimize Integer/Long.highestOneBit() >>> Reviewed-by: redestad, plevart >>> >>> ! src/java.base/share/classes/java/lang/Integer.java >>> ! src/java.base/share/classes/java/lang/Long.java >>> >>> Changeset: d2fd2581325b >>> Author: bpatel >>> Date: 2018-03-26 18:07 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/d2fd2581325b >>> >>> 8199278: Javadoc search results does not link to anchors on a page >>> Reviewed-by: jjg, ksrini >>> >>> ! >>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java >>> ! >>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java >>> ! >>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js >>> ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java >>> ! test/langtools/jdk/javadoc/doclet/testSearch/pkg/AnotherClass.java >>> >>> Changeset: ce86061aff12 >>> Author: bpatel >>> Date: 2018-03-26 21:30 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/ce86061aff12 >>> >>> 8199705: Docs.gmk needs to be updated to remove the -html5 option >>> Reviewed-by: erikj >>> >>> ! make/Docs.gmk >>> >>> Changeset: 752ecccb0b7f >>> Author: cushon >>> Date: 2018-03-27 13:48 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/752ecccb0b7f >>> >>> 8200301: deduplicate lambda methods >>> Reviewed-by: vromero, mcimadamore >>> >>> ! >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >>> + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java >>> + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeHasher.java >>> ! >>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties >>> ! >>> test/langtools/tools/javac/annotations/typeAnnotations/classfile/InstanceInitializer.java >>> ! >>> test/langtools/tools/javac/annotations/typeAnnotations/classfile/StaticInitializer.java >>> ! >>> test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java >>> + test/langtools/tools/javac/diags/examples/LambdaDeduplicate.java >>> + test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> + test/langtools/tools/javac/lambda/deduplication/DeduplicationTest.java >>> >>> Changeset: e376090dc07e >>> Author: alanb >>> Date: 2018-03-27 19:29 +0100 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e376090dc07e >>> >>> 8200256: java/nio/channels/AsynchronousChannelGroup/Basic.java fails >>> intermittently >>> Reviewed-by: chegar >>> >>> ! make/mapfiles/libnio/mapfile-linux >>> ! make/mapfiles/libnio/mapfile-macosx >>> ! make/mapfiles/libnio/mapfile-solaris >>> ! src/java.base/linux/classes/sun/nio/ch/EPollPort.java >>> ! src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java >>> ! src/java.base/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java >>> ! src/java.base/share/classes/sun/nio/ch/IOUtil.java >>> ! src/java.base/unix/native/libnio/ch/IOUtil.c >>> >>> Changeset: 5812849b5027 >>> Author: igerasim >>> Date: 2018-03-27 13:22 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5812849b5027 >>> >>> 8198358: Align organization of TwoStacksPlainSocketImp with >>> DualStackPlainSocketImpl [win] >>> Reviewed-by: chegar, clanger >>> >>> ! src/java.base/unix/native/libnet/PlainSocketImpl.c >>> ! src/java.base/windows/classes/java/net/DualStackPlainSocketImpl.java >>> ! src/java.base/windows/classes/java/net/TwoStacksPlainSocketImpl.java >>> ! src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c >>> ! src/java.base/windows/native/libnet/TwoStacksPlainSocketImpl.c >>> ! test/jdk/java/net/Socket/AddressTest.java >>> ! test/jdk/java/net/Socket/B6210227.java >>> ! test/jdk/java/net/Socket/CloseAvailable.java >>> ! test/jdk/java/net/Socket/DeadlockTest.java >>> ! test/jdk/java/net/Socket/HttpProxy.java >>> ! test/jdk/java/net/Socket/InheritHandle.java >>> ! test/jdk/java/net/Socket/InheritTimeout.java >>> ! test/jdk/java/net/Socket/LingerTest.java >>> ! test/jdk/java/net/Socket/LinkLocal.java >>> ! test/jdk/java/net/Socket/ProxyCons.java >>> ! test/jdk/java/net/Socket/RST.java >>> ! test/jdk/java/net/Socket/ReadTimeout.java >>> ! test/jdk/java/net/Socket/SetSoLinger.java >>> ! test/jdk/java/net/Socket/ShutdownInput.java >>> ! test/jdk/java/net/Socket/SocksConnectTimeout.java >>> ! test/jdk/java/net/Socket/TestAfterClose.java >>> ! test/jdk/java/net/Socket/TestClose.java >>> ! test/jdk/java/net/Socket/TestTcpNoDelay.java >>> ! test/jdk/java/net/Socket/Timeout.java >>> ! test/jdk/java/net/Socket/TrafficClass.java >>> ! test/jdk/java/net/Socket/UrgentDataTest.java >>> ! test/jdk/java/net/Socket/asyncClose/AsyncClose.java >>> ! test/jdk/java/net/Socket/asyncClose/BrokenPipe.java >>> ! test/jdk/java/net/Socket/setReuseAddress/Basic.java >>> ! test/jdk/java/net/Socket/setReuseAddress/Restart.java >>> ! test/jdk/java/net/SocketInputStream/SocketClosedException.java >>> ! test/jdk/java/net/SocketInputStream/SocketTimeout.java >>> ! test/jdk/java/net/SocketOption/ImmutableOptions.java >>> ! test/jdk/java/net/SocketOption/MinimumRcvBufferSize.java >>> ! test/jdk/java/net/SocketOption/SupportedOptionsSet.java >>> ! test/jdk/java/net/SocketOption/UnsupportedOptionsTest.java >>> >>> Changeset: f76e1ac74f28 >>> Author: redestad >>> Date: 2018-03-28 00:45 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/f76e1ac74f28 >>> >>> 8200289: Reduce number of exceptions created when calling >>> Lookup::canBeCached >>> Reviewed-by: sundar, psandoz >>> >>> ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java >>> >>> Changeset: b6671a111395 >>> Author: jjg >>> Date: 2018-03-27 16:25 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b6671a111395 >>> >>> 8199465: {@docRoot} references need to be updated to reflect new >>> module/package structure >>> Reviewed-by: martin, alanb, chegar >>> >>> ! src/java.base/share/classes/java/lang/CharSequence.java >>> ! src/java.base/share/classes/java/lang/Comparable.java >>> ! src/java.base/share/classes/java/lang/ProcessHandle.java >>> ! src/java.base/share/classes/java/lang/String.java >>> ! src/java.base/share/classes/java/lang/Thread.java >>> ! src/java.base/share/classes/java/lang/UnsupportedOperationException.java >>> ! src/java.base/share/classes/java/lang/module/Configuration.java >>> ! src/java.base/share/classes/java/time/Duration.java >>> ! src/java.base/share/classes/java/time/Instant.java >>> ! src/java.base/share/classes/java/time/LocalDate.java >>> ! src/java.base/share/classes/java/time/LocalDateTime.java >>> ! src/java.base/share/classes/java/time/LocalTime.java >>> ! src/java.base/share/classes/java/time/MonthDay.java >>> ! src/java.base/share/classes/java/time/OffsetDateTime.java >>> ! src/java.base/share/classes/java/time/OffsetTime.java >>> ! src/java.base/share/classes/java/time/Period.java >>> ! src/java.base/share/classes/java/time/Year.java >>> ! src/java.base/share/classes/java/time/YearMonth.java >>> ! src/java.base/share/classes/java/time/ZoneId.java >>> ! src/java.base/share/classes/java/time/ZoneOffset.java >>> ! src/java.base/share/classes/java/time/ZonedDateTime.java >>> ! src/java.base/share/classes/java/time/chrono/HijrahDate.java >>> ! src/java.base/share/classes/java/time/chrono/JapaneseDate.java >>> ! src/java.base/share/classes/java/time/chrono/MinguoDate.java >>> ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java >>> ! src/java.base/share/classes/java/util/AbstractCollection.java >>> ! src/java.base/share/classes/java/util/AbstractList.java >>> ! src/java.base/share/classes/java/util/AbstractMap.java >>> ! src/java.base/share/classes/java/util/AbstractQueue.java >>> ! src/java.base/share/classes/java/util/AbstractSequentialList.java >>> ! src/java.base/share/classes/java/util/AbstractSet.java >>> ! src/java.base/share/classes/java/util/ArrayDeque.java >>> ! src/java.base/share/classes/java/util/ArrayList.java >>> ! src/java.base/share/classes/java/util/Arrays.java >>> ! src/java.base/share/classes/java/util/Collection.java >>> ! src/java.base/share/classes/java/util/Collections.java >>> ! src/java.base/share/classes/java/util/Comparator.java >>> ! src/java.base/share/classes/java/util/Deque.java >>> ! src/java.base/share/classes/java/util/EnumMap.java >>> ! src/java.base/share/classes/java/util/EnumSet.java >>> ! src/java.base/share/classes/java/util/HashMap.java >>> ! src/java.base/share/classes/java/util/HashSet.java >>> ! src/java.base/share/classes/java/util/Hashtable.java >>> ! src/java.base/share/classes/java/util/IdentityHashMap.java >>> ! src/java.base/share/classes/java/util/Iterator.java >>> ! src/java.base/share/classes/java/util/LinkedHashMap.java >>> ! src/java.base/share/classes/java/util/LinkedHashSet.java >>> ! src/java.base/share/classes/java/util/LinkedList.java >>> ! src/java.base/share/classes/java/util/List.java >>> ! src/java.base/share/classes/java/util/ListIterator.java >>> ! src/java.base/share/classes/java/util/Map.java >>> ! src/java.base/share/classes/java/util/NavigableMap.java >>> ! src/java.base/share/classes/java/util/NavigableSet.java >>> ! src/java.base/share/classes/java/util/PriorityQueue.java >>> ! src/java.base/share/classes/java/util/Queue.java >>> ! src/java.base/share/classes/java/util/RandomAccess.java >>> ! src/java.base/share/classes/java/util/ResourceBundle.java >>> ! src/java.base/share/classes/java/util/Set.java >>> ! src/java.base/share/classes/java/util/SortedMap.java >>> ! src/java.base/share/classes/java/util/SortedSet.java >>> ! src/java.base/share/classes/java/util/TreeMap.java >>> ! src/java.base/share/classes/java/util/TreeSet.java >>> ! src/java.base/share/classes/java/util/Vector.java >>> ! src/java.base/share/classes/java/util/WeakHashMap.java >>> ! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java >>> ! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java >>> ! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java >>> ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java >>> ! >>> src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java >>> ! >>> src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java >>> ! src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java >>> ! >>> src/java.base/share/classes/java/util/concurrent/ConcurrentNavigableMap.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/CopyOnWriteArraySet.java >>> ! src/java.base/share/classes/java/util/concurrent/DelayQueue.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/SynchronousQueue.java >>> ! src/java.base/share/classes/java/util/concurrent/TransferQueue.java >>> ! src/java.base/share/classes/javax/net/ssl/SNIHostName.java >>> >>> Changeset: 951f29c9aef5 >>> Author: jlahoda >>> Date: 2018-03-28 10:24 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/951f29c9aef5 >>> >>> 8200135: >>> test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java is >>> failing after JDK-8194978 >>> Summary: Adjusting the expected number of exception table entries to the >>> recent changes in javac. >>> Reviewed-by: kvn >>> >>> ! test/hotspot/jtreg/ProblemList.txt >>> ! >>> test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java >>> >>> Changeset: 5fd26ab491fa >>> Author: rpatil >>> Date: 2018-03-26 17:33 +0530 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/5fd26ab491fa >>> >>> 8144300: http.nonProxyHosts value having wildcard * both at end and start >>> are not honored >>> Summary: added validation for wildcard at start and end >>> Reviewed-by: chegar, dfuchs, clanger >>> Contributed-by: pallavi.sonal at oracle.com >>> >>> ! src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >>> ! test/jdk/java/net/ProxySelector/B8035158.java >>> >>> Changeset: 0fdb76741c56 >>> Author: mcimadamore >>> Date: 2018-03-28 14:08 +0100 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/0fdb76741c56 >>> >>> 8200199: javac suggests to use var even when var is used >>> Summary: local var analyzer should use synthetic var type position to >>> decide if analysis is needed >>> Reviewed-by: jlahoda, vromero >>> >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java >>> + test/langtools/tools/javac/lvti/T8200199.java >>> + test/langtools/tools/javac/lvti/T8200199.out >>> >>> Changeset: 9925be430918 >>> Author: mcimadamore >>> Date: 2018-03-28 14:24 +0100 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/9925be430918 >>> >>> 8200355: local variable inference regression test generates classfile in >>> test folder >>> Summary: LVTI harness should generate files in jtreg scratch dir >>> Reviewed-by: vromero >>> >>> ! >>> test/langtools/tools/javac/lvti/harness/LocalVariableInferenceTester.java >>> >>> Changeset: 879cf9f18688 >>> Author: rriggs >>> Date: 2018-03-28 14:15 -0400 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/879cf9f18688 >>> >>> 8197595: Serialization javadoc should link to security best practices >>> Reviewed-by: lancea, mullan, ahgross >>> >>> ! src/java.base/share/classes/java/io/ObjectInputFilter.java >>> ! src/java.base/share/classes/java/io/ObjectInputStream.java >>> ! src/java.base/share/classes/java/io/Serializable.java >>> ! src/java.base/share/classes/java/io/package-info.java >>> >>> Changeset: bf53d82a51e5 >>> Author: ihse >>> Date: 2018-03-28 21:00 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/bf53d82a51e5 >>> >>> 8200357: Inline SoundLibraries.gmk into Lib-java.desktop.gmk >>> Reviewed-by: stuefe, erikj >>> >>> ! make/autoconf/flags-cflags.m4 >>> ! make/autoconf/platform.m4 >>> ! make/autoconf/spec.gmk.in >>> ! make/lib/Lib-java.desktop.gmk >>> - make/lib/SoundLibraries.gmk >>> >>> Changeset: 396ea30afbd5 >>> Author: ihse >>> Date: 2018-03-28 23:56 +0200 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/396ea30afbd5 >>> >>> 8200178: Remove mapfiles for JDK native libraries >>> Reviewed-by: erikj, alanb, mchung, prr, weijun >>> >>> ! make/lib/Awt2dLibraries.gmk >>> ! make/lib/CoreLibraries.gmk >>> ! make/lib/Lib-java.base.gmk >>> ! make/lib/Lib-java.desktop.gmk >>> ! make/lib/Lib-java.instrument.gmk >>> ! make/lib/Lib-java.management.gmk >>> ! make/lib/Lib-java.prefs.gmk >>> ! make/lib/Lib-java.rmi.gmk >>> ! make/lib/Lib-java.security.jgss.gmk >>> ! make/lib/Lib-java.smartcardio.gmk >>> ! make/lib/Lib-jdk.attach.gmk >>> ! make/lib/Lib-jdk.crypto.cryptoki.gmk >>> ! make/lib/Lib-jdk.crypto.ec.gmk >>> ! make/lib/Lib-jdk.crypto.ucrypto.gmk >>> ! make/lib/Lib-jdk.hotspot.agent.gmk >>> ! make/lib/Lib-jdk.jdi.gmk >>> ! make/lib/Lib-jdk.jdwp.agent.gmk >>> ! make/lib/Lib-jdk.management.agent.gmk >>> ! make/lib/Lib-jdk.management.gmk >>> ! make/lib/Lib-jdk.net.gmk >>> ! make/lib/Lib-jdk.pack.gmk >>> ! make/lib/Lib-jdk.sctp.gmk >>> ! make/lib/Lib-jdk.security.auth.gmk >>> ! make/lib/LibCommon.gmk >>> - make/mapfiles/libattach/mapfile-aix >>> - make/mapfiles/libattach/mapfile-linux >>> - make/mapfiles/libattach/mapfile-solaris >>> - make/mapfiles/libattach/reorder-windows-x86 >>> - make/mapfiles/libattach/reorder-windows-x86_64 >>> - make/mapfiles/libawt/mapfile-mawt-vers >>> - make/mapfiles/libawt/mapfile-vers >>> - make/mapfiles/libawt/mapfile-vers-linux >>> - make/mapfiles/libawt_headless/mapfile-vers >>> - make/mapfiles/libawt_headless/reorder-sparc >>> - make/mapfiles/libawt_headless/reorder-sparcv9 >>> - make/mapfiles/libawt_headless/reorder-x86 >>> - make/mapfiles/libawt_xawt/mapfile-vers >>> - make/mapfiles/libdt_socket/mapfile-vers >>> - make/mapfiles/libextnet/mapfile-linux >>> - make/mapfiles/libextnet/mapfile-solaris >>> - make/mapfiles/libfontmanager/mapfile-vers >>> - make/mapfiles/libinstrument/mapfile-vers >>> - make/mapfiles/libj2gss/mapfile-vers >>> - make/mapfiles/libj2pcsc/mapfile-vers >>> - make/mapfiles/libj2pkcs11/mapfile-vers >>> - make/mapfiles/libj2ucrypto/mapfile-vers >>> - make/mapfiles/libjaas/mapfile-vers >>> - make/mapfiles/libjava/mapfile-vers >>> - make/mapfiles/libjava/reorder-sparc >>> - make/mapfiles/libjava/reorder-sparcv9 >>> - make/mapfiles/libjava/reorder-x86 >>> - make/mapfiles/libjawt/mapfile-vers >>> - make/mapfiles/libjdwp/mapfile-vers >>> - make/mapfiles/libjimage/mapfile-vers >>> - make/mapfiles/libjli/mapfile-vers >>> - make/mapfiles/libjpeg/mapfile-vers >>> - make/mapfiles/libjpeg/reorder-sparc >>> - make/mapfiles/libjpeg/reorder-sparcv9 >>> - make/mapfiles/libjpeg/reorder-x86 >>> - make/mapfiles/libjsdt/mapfile-vers >>> - make/mapfiles/libjsig/mapfile-vers-solaris >>> - make/mapfiles/liblcms/mapfile-vers >>> - make/mapfiles/libmanagement/mapfile-vers >>> - make/mapfiles/libmanagement_agent/mapfile-vers >>> - make/mapfiles/libmanagement_ext/mapfile-vers >>> - make/mapfiles/libmlib_image/mapfile-vers >>> - make/mapfiles/libnet/mapfile-vers >>> - make/mapfiles/libnio/mapfile-aix >>> - make/mapfiles/libnio/mapfile-linux >>> - make/mapfiles/libnio/mapfile-macosx >>> - make/mapfiles/libnio/mapfile-solaris >>> - make/mapfiles/libnio/reorder-sparc >>> - make/mapfiles/libnio/reorder-sparcv9 >>> - make/mapfiles/libnio/reorder-x86 >>> - make/mapfiles/libprefs/mapfile-vers >>> - make/mapfiles/librmi/mapfile-vers >>> - make/mapfiles/libsaproc/mapfile-linux >>> - make/mapfiles/libsaproc/mapfile-macosx >>> - make/mapfiles/libsaproc/mapfile-solaris >>> - make/mapfiles/libsctp/mapfile-vers >>> - make/mapfiles/libsplashscreen/mapfile-vers >>> - make/mapfiles/libsunec/mapfile-vers >>> - make/mapfiles/libunpack/mapfile-vers >>> - make/mapfiles/libverify/mapfile-vers >>> - make/mapfiles/libverify/reorder-sparc >>> - make/mapfiles/libverify/reorder-sparcv9 >>> - make/mapfiles/libverify/reorder-x86 >>> - make/mapfiles/libzip/mapfile-vers >>> - make/mapfiles/libzip/reorder-sparc >>> - make/mapfiles/libzip/reorder-sparcv9 >>> - make/mapfiles/libzip/reorder-x86 >>> ! src/java.base/aix/native/libjsig/jsig.c >>> ! src/java.base/share/native/libjava/io_util.c >>> ! src/java.base/share/native/libjava/io_util.h >>> ! src/java.base/share/native/libjava/jni_util.h >>> ! src/java.base/share/native/libjimage/jimage.cpp >>> ! src/java.base/share/native/libjimage/jimage.hpp >>> ! src/java.base/share/native/libjli/args.c >>> ! src/java.base/share/native/libjli/java.c >>> ! src/java.base/share/native/libjli/java.h >>> ! src/java.base/share/native/libjli/jli_util.c >>> ! src/java.base/share/native/libjli/jli_util.h >>> ! src/java.base/share/native/libjli/manifest_info.h >>> ! src/java.base/share/native/libjli/parse_manifest.c >>> ! src/java.base/share/native/libnet/net_util.h >>> ! src/java.base/share/native/libzip/CRC32.c >>> ! src/java.base/share/native/libzip/zip_util.c >>> ! src/java.base/share/native/libzip/zip_util.h >>> ! src/java.base/solaris/native/libjsig/jsig.c >>> ! src/java.base/unix/native/libjava/FileOutputStream_md.c >>> ! src/java.base/unix/native/libjava/jni_util_md.c >>> ! src/java.base/unix/native/libjli/java_md_common.c >>> ! src/java.base/unix/native/libnet/net_util_md.c >>> ! src/java.base/unix/native/libnio/ch/Net.c >>> ! src/java.base/unix/native/libnio/ch/nio_util.h >>> ! src/java.base/windows/native/libjava/io_util_md.c >>> ! src/java.base/windows/native/libjava/io_util_md.h >>> ! src/java.base/windows/native/libjava/jni_util_md.c >>> ! src/java.base/windows/native/libjli/cmdtoargs.c >>> ! src/java.base/windows/native/libjli/java_md.c >>> ! src/java.base/windows/native/libnet/net_util_md.c >>> ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h >>> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_colors.c >>> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_colors.h >>> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.c >>> ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.h >>> ! src/java.desktop/share/native/libawt/awt/image/dither.c >>> ! src/java.desktop/share/native/libawt/awt/image/dither.h >>> ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h >>> ! src/java.desktop/share/native/libawt/java2d/SurfaceData.c >>> ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h >>> ! src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.c >>> ! src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.h >>> ! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.c >>> ! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h >>> ! src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c >>> ! src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.h >>> ! src/java.desktop/share/native/libmlib_image/mlib_image_proto.h >>> ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.c >>> ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h >>> ! src/java.desktop/unix/native/common/awt/img_util_md.h >>> ! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c >>> ! src/java.desktop/unix/native/libawt/awt/initIDs.c >>> ! src/java.desktop/unix/native/libsplashscreen/splashscreen_config.h >>> ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >>> ! src/java.desktop/windows/native/libawt/windows/img_util_md.h >>> ! src/java.desktop/windows/native/libsplashscreen/splashscreen_config.h >>> ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCrypto.c >>> ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCryptoMD.c >>> ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h >>> ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c >>> ! src/jdk.hotspot.agent/linux/native/libsaproc/proc_service.h >>> ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c >>> ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c >>> ! src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp >>> ! src/jdk.jdi/share/native/libdt_shmem/shmemBack.c >>> ! src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>> >>> Changeset: 77bff7a757a4 >>> Author: martin >>> Date: 2018-03-28 21:13 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/77bff7a757a4 >>> >>> 8200116: ConstructInflaterOutput, ConstructDeflaterInput still spamming >>> test logs >>> Summary: end() should always expect to be called eventually >>> Reviewed-by: sherman, ulfzibis >>> >>> ! test/jdk/java/util/zip/ConstructDeflaterInput.java >>> ! test/jdk/java/util/zip/ConstructInflaterOutput.java >>> >>> Changeset: d6d1c06becda >>> Author: martin >>> Date: 2018-03-28 21:14 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/d6d1c06becda >>> >>> 8200124: Various cleanups in jar/zip >>> Reviewed-by: sherman, ulfzibis >>> >>> ! src/java.base/share/classes/java/util/jar/Manifest.java >>> ! src/java.base/share/classes/java/util/zip/ZipCoder.java >>> ! src/java.base/share/classes/java/util/zip/ZipFile.java >>> ! src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java >>> >>> Changeset: e5679a6661d6 >>> Author: martin >>> Date: 2018-03-28 21:14 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/e5679a6661d6 >>> >>> 8200310: Avoid charset lookup machinery in >>> java.nio.charset.StandardCharsets >>> Reviewed-by: sherman, ulfzibis >>> >>> ! src/java.base/share/classes/java/lang/StringCoding.java >>> ! src/java.base/share/classes/java/nio/charset/Charset.java >>> ! src/java.base/share/classes/java/nio/charset/StandardCharsets.java >>> ! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java >>> ! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template >>> ! src/java.base/share/classes/sun/nio/cs/US_ASCII.java >>> ! src/java.base/share/classes/sun/nio/cs/UTF_16.java >>> ! src/java.base/share/classes/sun/nio/cs/UTF_16BE.java >>> ! src/java.base/share/classes/sun/nio/cs/UTF_16LE.java >>> ! src/java.base/share/classes/sun/nio/cs/UTF_8.java >>> ! test/jdk/java/nio/charset/StandardCharsets/Standard.java >>> >>> Changeset: ae873285a39c >>> Author: xiaofeya >>> Date: 2018-03-28 21:57 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/ae873285a39c >>> >>> 8196668: revisit test SunPackageAccess and GrantedSunPackageAccess >>> Reviewed-by: mchung >>> >>> + test/jdk/java/lang/SecurityManager/PackageAccessTest.java >>> + test/jdk/java/lang/SecurityManager/empty.policy >>> + test/jdk/java/lang/SecurityManager/test.policy >>> >>> Changeset: b85603908ae4 >>> Author: erikj >>> Date: 2018-03-29 08:52 -0700 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/b85603908ae4 >>> >>> 8200409: jdk11 nightly solaris sparc build failure >>> Reviewed-by: alanb, tbell >>> >>> ! make/lib/Lib-java.base.gmk >>> + make/mapfiles/libjsig/mapfile-vers-solaris >>> ! src/java.base/solaris/native/libjsig/jsig.c >>> >>> Changeset: a11d3a5ca20b >>> Author: chegar >>> Date: 2018-03-29 20:12 +0100 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/a11d3a5ca20b >>> >>> 8200304: TwoStacksPlainDatagramSocketImpl and socket cleaner >>> Reviewed-by: alanb, dfuchs, rriggs >>> >>> ! >>> src/java.base/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java >>> ! src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c >>> >>> Changeset: 1f9dd2360b17 >>> Author: jwilhelm >>> Date: 2018-03-24 01:08 +0100 >>> URL: http://hg.openjdk.java.net/zgc/zgc/rev/1f9dd2360b17 >>> >>> Merge >>> >>> ! make/autoconf/hotspot.m4 >>> + src/hotspot/share/gc/cms/cmsCardTable.cpp >>> - src/hotspot/share/gc/cms/parCardTableModRefBS.cpp >>> ! src/hotspot/share/gc/g1/g1BarrierSet.cpp >>> ! src/hotspot/share/gc/g1/g1BarrierSet.hpp >>> ! src/hotspot/share/gc/g1/g1Policy.hpp >>> ! src/hotspot/share/gc/parallel/psCardTable.cpp >>> - src/hotspot/share/gc/shared/barrierSet.inline.hpp >>> ! src/hotspot/share/gc/shared/cardTable.hpp >>> + src/hotspot/share/gc/shared/cardTableBarrierSet.cpp >>> + src/hotspot/share/gc/shared/cardTableBarrierSet.hpp >>> + src/hotspot/share/gc/shared/cardTableBarrierSet.inline.hpp >>> - src/hotspot/share/gc/shared/cardTableModRefBS.cpp >>> - src/hotspot/share/gc/shared/cardTableModRefBS.hpp >>> - src/hotspot/share/gc/shared/cardTableModRefBS.inline.hpp >>> - src/hotspot/share/prims/jvmtiEnter.hpp From ci_notify at linaro.org Tue Apr 17 00:34:55 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 17 Apr 2018 00:34:55 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <794832109.7734.1523925295580.JavaMail.jenkins@4a1669f5d0e4> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/105/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/19 pass: 7,598; fail: 720; error: 23 Build 1: aarch64/2018/jan/21 pass: 7,595; fail: 717; error: 29 Build 2: aarch64/2018/feb/21 pass: 7,623; fail: 749; error: 27 Build 3: aarch64/2018/mar/15 pass: 7,693; fail: 692; error: 20 Build 4: aarch64/2018/mar/17 pass: 7,654; fail: 727; error: 24 Build 5: aarch64/2018/mar/19 pass: 7,657; fail: 722; error: 26 Build 6: aarch64/2018/mar/21 pass: 7,652; fail: 732; error: 21 Build 7: aarch64/2018/mar/23 pass: 7,629; fail: 752; error: 24 Build 8: aarch64/2018/mar/25 pass: 7,778; fail: 629; error: 20 Build 9: aarch64/2018/mar/27 pass: 7,773; fail: 634; error: 20 Build 10: aarch64/2018/mar/29 pass: 7,790; fail: 617; error: 20 Build 11: aarch64/2018/mar/31 pass: 7,766; fail: 643; error: 18 Build 12: aarch64/2018/apr/05 pass: 7,787; fail: 619; error: 21 Build 13: aarch64/2018/apr/07 pass: 7,781; fail: 632; error: 18 Build 14: aarch64/2018/apr/15 pass: 7,824; fail: 583; error: 29 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/19 pass: 3,825; fail: 5; error: 5 Build 1: aarch64/2018/jan/21 pass: 3,824; fail: 5; error: 6 Build 2: aarch64/2018/feb/21 pass: 3,831; fail: 6; error: 9 Build 3: aarch64/2018/mar/15 pass: 3,842; fail: 6; error: 4 Build 4: aarch64/2018/mar/17 pass: 3,842; fail: 6; error: 4 Build 5: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 6: aarch64/2018/mar/21 pass: 3,844; fail: 6; error: 2 Build 7: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 8: aarch64/2018/mar/25 pass: 3,844; fail: 6; error: 7 Build 9: aarch64/2018/mar/27 pass: 3,847; fail: 6; error: 4 Build 10: aarch64/2018/mar/29 pass: 3,849; fail: 6; error: 2 Build 11: aarch64/2018/mar/31 pass: 3,851; fail: 6 Build 12: aarch64/2018/apr/05 pass: 3,851; fail: 6 Build 13: aarch64/2018/apr/07 pass: 3,851; fail: 6; error: 3 Build 14: aarch64/2018/apr/15 pass: 3,855; fail: 6; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/19 pass: 7,620; fail: 700; error: 21 Build 1: aarch64/2018/jan/21 pass: 7,600; fail: 714; error: 27 Build 2: aarch64/2018/feb/21 pass: 7,656; fail: 716; error: 27 Build 3: aarch64/2018/mar/15 pass: 7,680; fail: 703; error: 22 Build 4: aarch64/2018/mar/17 pass: 7,670; fail: 711; error: 24 Build 5: aarch64/2018/mar/19 pass: 7,669; fail: 714; error: 22 Build 6: aarch64/2018/mar/21 pass: 7,675; fail: 711; error: 19 Build 7: aarch64/2018/mar/23 pass: 7,643; fail: 740; error: 22 Build 8: aarch64/2018/mar/25 pass: 7,811; fail: 599; error: 17 Build 9: aarch64/2018/mar/27 pass: 7,794; fail: 614; error: 19 Build 10: aarch64/2018/mar/29 pass: 7,823; fail: 585; error: 19 Build 11: aarch64/2018/mar/31 pass: 7,798; fail: 611; error: 18 Build 12: aarch64/2018/apr/05 pass: 7,816; fail: 593; error: 18 Build 13: aarch64/2018/apr/07 pass: 7,797; fail: 619; error: 15 Build 14: aarch64/2018/apr/15 pass: 7,849; fail: 560; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/19 pass: 3,829; fail: 5; error: 1 Build 1: aarch64/2018/jan/21 pass: 3,827; fail: 5; error: 3 Build 2: aarch64/2018/feb/21 pass: 3,838; fail: 6; error: 2 Build 3: aarch64/2018/mar/15 pass: 3,845; fail: 6; error: 1 Build 4: aarch64/2018/mar/17 pass: 3,841; fail: 6; error: 5 Build 5: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 6: aarch64/2018/mar/21 pass: 3,841; fail: 6; error: 5 Build 7: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 8: aarch64/2018/mar/25 pass: 3,850; fail: 6; error: 1 Build 9: aarch64/2018/mar/27 pass: 3,848; fail: 6; error: 3 Build 10: aarch64/2018/mar/29 pass: 3,848; fail: 6; error: 3 Build 11: aarch64/2018/mar/31 pass: 3,850; fail: 6; error: 1 Build 12: aarch64/2018/apr/05 pass: 3,851; fail: 6 Build 13: aarch64/2018/apr/07 pass: 3,853; fail: 5; error: 2 Build 14: aarch64/2018/apr/15 pass: 3,854; fail: 6; error: 4 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.32x Relative performance: Server critical-jOPS (nc): 0.30x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 24.68, Server: 38.99 Client 24.68 / Client 2014-04-01 (43.00): 0.57x Server 38.99 / Server 2014-04-01 (71.00): 0.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2018-01-20 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/019/results/ 2018-01-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/021/results/ 2018-02-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/052/results/ 2018-03-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/074/results/ 2018-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/076/results/ 2018-03-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/078/results/ 2018-03-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/080/results/ 2018-03-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/082/results/ 2018-03-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/084/results/ 2018-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/086/results/ 2018-03-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/088/results/ 2018-03-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/090/results/ 2018-04-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/095/results/ 2018-04-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/097/results/ 2018-04-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/105/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Wed Apr 18 04:41:20 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 18 Apr 2018 04:41:20 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <636552703.8165.1524026480730.JavaMail.jenkins@4a1669f5d0e4> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/107/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/21 pass: 7,595; fail: 717; error: 29 Build 1: aarch64/2018/feb/21 pass: 7,623; fail: 749; error: 27 Build 2: aarch64/2018/mar/15 pass: 7,693; fail: 692; error: 20 Build 3: aarch64/2018/mar/17 pass: 7,654; fail: 727; error: 24 Build 4: aarch64/2018/mar/19 pass: 7,657; fail: 722; error: 26 Build 5: aarch64/2018/mar/21 pass: 7,652; fail: 732; error: 21 Build 6: aarch64/2018/mar/23 pass: 7,629; fail: 752; error: 24 Build 7: aarch64/2018/mar/25 pass: 7,778; fail: 629; error: 20 Build 8: aarch64/2018/mar/27 pass: 7,773; fail: 634; error: 20 Build 9: aarch64/2018/mar/29 pass: 7,790; fail: 617; error: 20 Build 10: aarch64/2018/mar/31 pass: 7,766; fail: 643; error: 18 Build 11: aarch64/2018/apr/05 pass: 7,787; fail: 619; error: 21 Build 12: aarch64/2018/apr/07 pass: 7,781; fail: 632; error: 18 Build 13: aarch64/2018/apr/15 pass: 7,824; fail: 583; error: 29 Build 14: aarch64/2018/apr/17 pass: 7,800; fail: 621; error: 15 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/21 pass: 3,824; fail: 5; error: 6 Build 1: aarch64/2018/feb/21 pass: 3,831; fail: 6; error: 9 Build 2: aarch64/2018/mar/15 pass: 3,842; fail: 6; error: 4 Build 3: aarch64/2018/mar/17 pass: 3,842; fail: 6; error: 4 Build 4: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 5: aarch64/2018/mar/21 pass: 3,844; fail: 6; error: 2 Build 6: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 7: aarch64/2018/mar/25 pass: 3,844; fail: 6; error: 7 Build 8: aarch64/2018/mar/27 pass: 3,847; fail: 6; error: 4 Build 9: aarch64/2018/mar/29 pass: 3,849; fail: 6; error: 2 Build 10: aarch64/2018/mar/31 pass: 3,851; fail: 6 Build 11: aarch64/2018/apr/05 pass: 3,851; fail: 6 Build 12: aarch64/2018/apr/07 pass: 3,851; fail: 6; error: 3 Build 13: aarch64/2018/apr/15 pass: 3,855; fail: 6; error: 3 Build 14: aarch64/2018/apr/17 pass: 3,856; fail: 6; error: 2 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/21 pass: 7,600; fail: 714; error: 27 Build 1: aarch64/2018/feb/21 pass: 7,656; fail: 716; error: 27 Build 2: aarch64/2018/mar/15 pass: 7,680; fail: 703; error: 22 Build 3: aarch64/2018/mar/17 pass: 7,670; fail: 711; error: 24 Build 4: aarch64/2018/mar/19 pass: 7,669; fail: 714; error: 22 Build 5: aarch64/2018/mar/21 pass: 7,675; fail: 711; error: 19 Build 6: aarch64/2018/mar/23 pass: 7,643; fail: 740; error: 22 Build 7: aarch64/2018/mar/25 pass: 7,811; fail: 599; error: 17 Build 8: aarch64/2018/mar/27 pass: 7,794; fail: 614; error: 19 Build 9: aarch64/2018/mar/29 pass: 7,823; fail: 585; error: 19 Build 10: aarch64/2018/mar/31 pass: 7,798; fail: 611; error: 18 Build 11: aarch64/2018/apr/05 pass: 7,816; fail: 593; error: 18 Build 12: aarch64/2018/apr/07 pass: 7,797; fail: 619; error: 15 Build 13: aarch64/2018/apr/15 pass: 7,849; fail: 560; error: 27 Build 14: aarch64/2018/apr/17 pass: 7,825; fail: 593; error: 18 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/jan/21 pass: 3,827; fail: 5; error: 3 Build 1: aarch64/2018/feb/21 pass: 3,838; fail: 6; error: 2 Build 2: aarch64/2018/mar/15 pass: 3,845; fail: 6; error: 1 Build 3: aarch64/2018/mar/17 pass: 3,841; fail: 6; error: 5 Build 4: aarch64/2018/mar/19 pass: 3,843; fail: 6; error: 3 Build 5: aarch64/2018/mar/21 pass: 3,841; fail: 6; error: 5 Build 6: aarch64/2018/mar/23 pass: 3,843; fail: 6; error: 3 Build 7: aarch64/2018/mar/25 pass: 3,850; fail: 6; error: 1 Build 8: aarch64/2018/mar/27 pass: 3,848; fail: 6; error: 3 Build 9: aarch64/2018/mar/29 pass: 3,848; fail: 6; error: 3 Build 10: aarch64/2018/mar/31 pass: 3,850; fail: 6; error: 1 Build 11: aarch64/2018/apr/05 pass: 3,851; fail: 6 Build 12: aarch64/2018/apr/07 pass: 3,853; fail: 5; error: 2 Build 13: aarch64/2018/apr/15 pass: 3,854; fail: 6; error: 4 Build 14: aarch64/2018/apr/17 pass: 3,854; fail: 6; error: 4 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.99x Relative performance: Server critical-jOPS (nc): 0.83x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 68.52, Server: 114.76 Client 68.52 / Client 2014-04-01 (43.00): 1.59x Server 114.76 / Server 2014-04-01 (71.00): 1.62x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2018-01-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/021/results/ 2018-02-22 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/052/results/ 2018-03-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/074/results/ 2018-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/076/results/ 2018-03-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/078/results/ 2018-03-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/080/results/ 2018-03-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/082/results/ 2018-03-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/084/results/ 2018-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/086/results/ 2018-03-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/088/results/ 2018-03-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/090/results/ 2018-04-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/095/results/ 2018-04-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/097/results/ 2018-04-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/105/results/ 2018-04-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/107/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From goetz.lindenmaier at sap.com Wed Apr 18 08:09:12 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Apr 2018 08:09:12 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. Message-ID: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Hi, I would like to print a more verbose text on ArrayIndexOutOfBounds exception that not only mentions the index, but also the length of the array accessed. See the bug for documentation of the change of the message. http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ @aarch/arm people: I edited the aarch/arm files. Could you please verify this is correct? I can not build on these platforms. The code on all the other platforms is tested with all the jtreg and jck tests etc. Best regards, Goetz. From david.holmes at oracle.com Wed Apr 18 08:54:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Apr 2018 18:54:48 +1000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> Adding core-libs-dev as you're changing java.lang.ArrayIndexOutOfBoundsException. I appreciate the intent here but I find the messages excessively verbose. The basic error is: index N is outside range [0, length-1] David On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > Hi, > > I would like to print a more verbose text on ArrayIndexOutOfBounds exception > that not only mentions the index, but also the length of the array accessed. > See the bug for documentation of the change of the message. > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > @aarch/arm people: > I edited the aarch/arm files. Could you please verify this is correct? > I can not build on these platforms. > > The code on all the other platforms is tested with all the jtreg and jck tests etc. > > Best regards, > Goetz. > > From stuart.monteith at linaro.org Wed Apr 18 11:12:38 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 18 Apr 2018 12:12:38 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: Hello, On Aarch64 I'm getting the following during jlinking in the build process: # Internal Error (/home/stuart/repos/jdk/src/hotspot/share/c1/c1_LIR.hpp:413), pid=27882, tid=27893 # assert(is_single_cpu() && !is_virtual()) failed: type check Stack: [0x0000010003de0000,0x0000010003fe0000], sp=0x0000010003fdcff0, free space=2035k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xf39cd8] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, std::__va_list)+0x80 V [libjvm.so+0x6efbb4] report_vm_error(char const*, int, char const*, char const*, ...)+0x14c V [libjvm.so+0x43f0d0] LIR_OprDesc::cpu_regnr() const+0xa8 V [libjvm.so+0x473120] LIR_OprDesc::as_register() const+0x14 V [libjvm.so+0x432ae0] LIR_OprDesc::as_pointer_register()+0xbc V [libjvm.so+0x42ff08] RangeCheckStub::emit_code(LIR_Assembler*)+0x1ac V [libjvm.so+0x4816e4] LIR_Assembler::emit_stubs(CodeStubList*)+0x100 V [libjvm.so+0x48172c] LIR_Assembler::emit_slow_case_stubs()+0x20 V [libjvm.so+0x434d4c] Compilation::emit_code_epilog(LIR_Assembler*)+0x3c V [libjvm.so+0x4350b0] Compilation::emit_code_body()+0x140 V [libjvm.so+0x435388] Compilation::compile_java_method()+0x254 V [libjvm.so+0x4356d0] Compilation::compile_method()+0xd8 V [libjvm.so+0x435e74] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x24c V [libjvm.so+0x439cf8] Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xbc V [libjvm.so+0x689be8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x5cc V [libjvm.so+0x688ce8] CompileBroker::compiler_thread_loop()+0x2a0 V [libjvm.so+0xebdd80] compiler_thread_entry(JavaThread*, Thread*)+0x9c V [libjvm.so+0xeb8b7c] JavaThread::thread_main_inner()+0x1a8 V [libjvm.so+0xeb89c4] JavaThread::run()+0x1ac V [libjvm.so+0xcf0048] thread_native_entry(Thread*)+0x17c C [libpthread.so.0+0x7e2c] start_thread+0xb0 The error is specifically C1, C2 and the interpreter are unaffected. On 18 April 2018 at 09:09, Lindenmaier, Goetz wrote: > Hi, > > I would like to print a more verbose text on ArrayIndexOutOfBounds exception > that not only mentions the index, but also the length of the array accessed. > See the bug for documentation of the change of the message. > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > @aarch/arm people: > I edited the aarch/arm files. Could you please verify this is correct? > I can not build on these platforms. > > The code on all the other platforms is tested with all the jtreg and jck tests etc. > > Best regards, > Goetz. > > From aph at redhat.com Wed Apr 18 13:52:53 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Apr 2018 14:52:53 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: <040154fc-28da-0a5c-1f39-b138ab24d187@redhat.com> On 04/18/2018 12:12 PM, Stuart Monteith wrote: > On Aarch64 I'm getting the following during jlinking in the build process: DO you want to debug that or shall I? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Wed Apr 18 15:55:53 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 18 Apr 2018 16:55:53 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <040154fc-28da-0a5c-1f39-b138ab24d187@redhat.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <040154fc-28da-0a5c-1f39-b138ab24d187@redhat.com> Message-ID: Hi, I've had a look. Stack trace in gdb for reference.. message=0x3ffb77e0790 "assert(is_single_cpu() && !is_virtual()) failed", detail_fmt=0x3ffb77e0780 "type check", detail_args=...) at /home/stuart/repos/jdk/src/hotspot/share/utilities/vmError.cpp:1244 #15 0x000003ffb6ebfbb4 in report_vm_error (file=0x3ffb77e07c0 "/home/stuart/repos/jdk/src/hotspot/share/c1/c1_LIR.hpp", line=0x19d, error_msg=0x3ffb77e0790 "assert(is_single_cpu() && !is_virtual()) failed", detail_fmt=0x3ffb77e0780 "type check") at /home/stuart/repos/jdk/src/hotspot/share/utilities/debug.cpp:230 #16 0x000003ffb6c0f0d0 in LIR_OprDesc::cpu_regnr (this=0x0) at /home/stuart/repos/jdk/src/hotspot/share/c1/c1_LIR.hpp:413 #17 0x000003ffb6c43120 in LIR_OprDesc::as_register (this=0x0) at /home/stuart/repos/jdk/src/hotspot/share/c1/c1_LIR.cpp:34 #18 0x000003ffb6c02ae0 in LIR_OprDesc::as_pointer_register (this=0x0) at /home/stuart/repos/jdk/src/hotspot/share/c1/c1_LIR.hpp:439 #19 0x000003ffb6bfff08 in RangeCheckStub::emit_code (this=0x3ffb0847e90, ce=0x3ff41a6d290) at /home/stuart/repos/jdk/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp:76 c1_CodeStubs_aarch64.cpp: RangeCheckStub::emit_code(LIR_Assembler* ce) is being passed a NULL _array, and that is what is failing the assertions. C1 is, from the replay log, compiling "java/nio/HeapByteBuffer". For these methods, an array is not being passed.. The method void LIRGenerator::do_NIOCheckIndex(Intrinsic* x) creates RangeCheckStub with a NULL array parameter. When it comes to RangeCheckStub::emit_code, the following is failing as _array is NULL: __ mov(rscratch2, _array->as_pointer_register()); Taking "Runtime1::generate_exception_throw" as an example of what is called, it either takes no parameters, or now two parameters. Of course, the following method doesn't take an array: static void throw_index_exception(JavaThread* thread, int index); which is what is called by the stubs. I would expect it to be: static void throw_index_exception(JavaThread* thread, int index, array); I'll keep digging. On 18 April 2018 at 14:52, Andrew Haley wrote: > On 04/18/2018 12:12 PM, Stuart Monteith wrote: >> On Aarch64 I'm getting the following during jlinking in the build process: > > DO you want to debug that or shall I? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Apr 18 16:09:10 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 18 Apr 2018 19:09:10 +0300 Subject: [aarch64-port-dev ] RFR: 8189103 - AARCH64: optimize String indexOf intrinsic Message-ID: Hi all, please review patch for JDK-8189103: AARCH64: optimize String indexOf intrinsic indexOf instrinsic initially had 6 different algorithms(selected depending on strings length): pattern length 1, 2, 3, 4, , Boyer Moore algorithm. This patch consists of few several improvement ideas: 1) minimally updated algorithms for pattern length 1,2,3,4, by removing 1 unnecessary dependent instruction and moving 1 common instruction into common part for length 2,3,4, . It slightly improves performance for these cases(about 1%). 2) large update of Boyer Moore algorithm implementation by increasing search table size from 128 to 256 to remove few branches for Latin1 encoding cases and also improve performance for cases when Latin1 symbols with values >128 are met. This patch also significantly improves search of Latin1 string inside UTF string by upgrading algorithm logic(the idea is to skip symbols in case pure UTF symbol is met in source string). 3) separate implementation for generic linear search is added(moved to stub). It requires more time for initialization, but is faster after initialization is done, which allows to improve performance for long strings 4) removed dead code in .ad file. LU case (search of UTF string inside Latin1 string) always return -1 and handled in java before calling this instrinsic Benchmarking and results(used Cavium ThunderX (T88), Cavium ThunderX2 (T99) and Cortex A73): I created microbenchmark, which measures different pattern size search in different source size string: http://cr.openjdk.java.net/~dpochepk/8189103/IndexOfBench.java Overall results: - about same results for minimally updated algorithm paths - large difference for Boyer Moore algorithm: up to x40 improvement for large string with variety of different characters - significant difference for sizes affected by new linear search in stub: up to 30% improvement Results matrix is large: http://cr.openjdk.java.net/~dpochepk/8189103/str_indexof_result.xls Raw results: *.txt files in http://cr.openjdk.java.net/~dpochepk/8189103/ webrev: http://cr.openjdk.java.net/%7Edpochepk/8189103/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8189103 Testing: - run hotspot jtreg tests(compiler, runtime, gc) over patched release build and found no new failures. - run additional "brute force" tests which checks all index combinations for specified lengths(takes much time to run): http://cr.openjdk.java.net/~dpochepk/8189103/IndexOfTest.java using both release and fastdebug builds Thanks, Dmitrij From aph at redhat.com Thu Apr 19 11:00:05 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Apr 2018 12:00:05 +0100 Subject: [aarch64-port-dev ] RFR: 8189103 - AARCH64: optimize String indexOf intrinsic In-Reply-To: References: Message-ID: <83a68544-a4f8-eafa-5e20-5ec735412835@redhat.com> On 04/18/2018 05:09 PM, Dmitrij Pochepko wrote: > Hi all, > > please review patch for JDK-8189103: AARCH64: optimize String indexOf > intrinsic Thanks. I'm looking at this. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu Apr 19 12:24:55 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Apr 2018 12:24:55 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> Message-ID: <5be0f86df2834aa8a881206ba285011e@sap.com> Hi, New webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ I admit my wording is not optimal. It's because I extracted this change from a bigger one. Our message reads like this: Object [] oa1 = new Object[10] oa1[12] "ArrayIndexOutOfBoundsException while trying to load from index 12 of an object array with length 10, loaded from local variable 'oa1'" ... which seems not optimal, either. But it mentions the type (object), the operation (load, store etc ...) and the variable name. Naming the array is quite detailed if it is in a complex expression (like returned from a call). I'll contribute more of this if appreciated, this is a first step. Printing "index N is outside range [0, length-1]" is problematic for length '0'. I followed the proposal by Roger: "Index -1 out-of-bounds for length 10." I removed the change to ArrayIndexOutOfBoundsException.java. I extended the test to cover the exception thrown in arraycopy better and added the elementary type to the message text. This probably needs improvement in the text, too. There are (currently) these cases: bject[] oa1 = new Object[10]; Object[] oa2 = new Object[5]; System.arraycopy(oa1, -17, oa2, 0, 5); "while trying to copy from index -17 of an object array with length 10"); System.arraycopy(oa1, 2, oa2, -18, 5); "while trying to copy to index -18 of an object array with length 5"); System.arraycopy(oa1, 2, oa2, 0, -19); "while trying to copy a negative range -19 from an object array with length 10 to an object array with length 5"); System.arraycopy(oa1, 8, oa2, 0, 5); "while trying to copy from index 13 of an object array with length 10"); System.arraycopy(oa1, 1, oa2, 0, 7); "while trying to copy to index 7 of an object array with length 5"); double[] ta1 = new double[10]; double[] ta2 = new double[5]; System.arraycopy(ta1, -17, ta2, 0, 5); "while trying to copy from index -17 of a doubl array with length 10"); System.arraycopy(ta1, 2, ta2, -18, 5); "while trying to copy to index -18 of a double array with length 5"); System.arraycopy(ta1, 2, ta2, 0, -19); "while trying to copy a negative range -19 from a double array with length 10 to a double array with length 5"); System.arraycopy(ta1, 8, ta2, 0, 5); "while trying to copy from index 13 of a double array with length 10"); System.arraycopy(ta1, 1, ta2, 0, 7); "while trying to copy to index 7 of a double array with length 5"); Maybe it should say: Arraycopy source index -1 out-of-bounds for double array of length 10. Arraycopy target index 10 out-of-bounds for object array of length 10. Negative range -19 when copying from an object array of length 10 to an object array of length 5. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 18. April 2018 10:55 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Adding core-libs-dev as you're changing > java.lang.ArrayIndexOutOfBoundsException. > > I appreciate the intent here but I find the messages excessively > verbose. The basic error is: > > index N is outside range [0, length-1] > > David > > On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to print a more verbose text on ArrayIndexOutOfBounds > exception > > that not only mentions the index, but also the length of the array accessed. > > See the bug for documentation of the change of the message. > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > > > @aarch/arm people: > > I edited the aarch/arm files. Could you please verify this is correct? > > I can not build on these platforms. > > > > The code on all the other platforms is tested with all the jtreg and jck tests > etc. > > > > Best regards, > > Goetz. > > > > From stuart.monteith at linaro.org Thu Apr 19 12:25:40 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 19 Apr 2018 13:25:40 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: Hello Goetz, In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just need to guard the emission of rscratch2 - you don't use it in one of the cases, something like: if (!_throw_index_out_of_bounds_exception) { __ mov(rscratch2, _array->as_pointer_register()); } Once I can run the unit tests, I'm seeing failures in your unit test like: java.lang.AssertionError: expected [trying to access index -5 of an array with length 0] but found [trying to access index -5 of an array with length -1459548190] BR, Stuart On 18 April 2018 at 09:09, Lindenmaier, Goetz wrote: > Hi, > > I would like to print a more verbose text on ArrayIndexOutOfBounds exception > that not only mentions the index, but also the length of the array accessed. > See the bug for documentation of the change of the message. > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > @aarch/arm people: > I edited the aarch/arm files. Could you please verify this is correct? > I can not build on these platforms. > > The code on all the other platforms is tested with all the jtreg and jck tests etc. > > Best regards, > Goetz. > > From goetz.lindenmaier at sap.com Thu Apr 19 14:36:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Apr 2018 14:36:19 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: Hi Stuart, thanks a lot for helping out here. I added below patch to my latest webrev (replaced it in-place): http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ The remaining problem looks like the array argument does not reach the method that prints the message properly. Did I get a register wrong? Did I use a wrong argument register, or does the untangling of registers in overwrite something? Is it correct to use mov and not movw in templateInterpreterGenerator_aarch64.cpp? Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" here is stupid, it seems to cause unnecessary register moves. But it's similar on all platforms.) The test runs several times, assuring it's C1, C2 and Xint. This should help you to narrow down the problem. Best regards, Goetz. diff -r 3fe33d48aa16 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 16:06:23 2018 +0200 @@ -73,9 +73,10 @@ } else { __ mov(rscratch1, _index->as_jint()); } - __ mov(rscratch2, _array->as_pointer_register()); Runtime1::StubID stub_id; if (_throw_index_out_of_bounds_exception) { + assert(_array != NULL, "sanity"); + __ mov(rscratch2, _array->as_pointer_register()); stub_id = Runtime1::throw_index_exception_id; } else { stub_id = Runtime1::throw_range_check_failed_id; > -----Original Message----- > From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > Sent: Donnerstag, 19. April 2018 14:26 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32-port- > dev at openjdk.java.net > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hello Goetz, > In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just > need to guard the emission of rscratch2 - you don't use it in one of > the cases, something like: > > if (!_throw_index_out_of_bounds_exception) { > __ mov(rscratch2, _array->as_pointer_register()); > } > > > Once I can run the unit tests, I'm seeing failures in your unit test like: > > java.lang.AssertionError: expected [trying to access index -5 of an > array with length 0] but found [trying to access index -5 of an array > with length -1459548190] > > > BR, > Stuart > > > On 18 April 2018 at 09:09, Lindenmaier, Goetz > wrote: > > Hi, > > > > I would like to print a more verbose text on ArrayIndexOutOfBounds > exception > > that not only mentions the index, but also the length of the array accessed. > > See the bug for documentation of the change of the message. > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > > > @aarch/arm people: > > I edited the aarch/arm files. Could you please verify this is correct? > > I can not build on these platforms. > > > > The code on all the other platforms is tested with all the jtreg and jck tests > etc. > > > > Best regards, > > Goetz. > > > > From stuart.monteith at linaro.org Thu Apr 19 15:09:11 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 19 Apr 2018 16:09:11 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: Hi, I'm trying to work through what's going on here. With C1 not crashing, I'll check the behaviour of the interpreter and C2. I'm doing explicitly with -Xint, etc. WIth -Xint I definitely get the error. You have the condition the wrong way round - _throw_index_out_of_bounds_exception is true when array is NULL. BR, Stuart On 19 April 2018 at 15:36, Lindenmaier, Goetz wrote: > Hi Stuart, > > thanks a lot for helping out here. > I added below patch to my latest webrev (replaced it in-place): > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > The remaining problem looks like the array argument does not > reach the method that prints the message properly. > Did I get a register wrong? > Did I use a wrong argument register, or does the untangling > of registers in overwrite something? > Is it correct to use mov and not movw in templateInterpreterGenerator_aarch64.cpp? > Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" here is stupid, > it seems to cause unnecessary register moves. But it's similar on all platforms.) > > The test runs several times, assuring it's C1, C2 and Xint. > This should help you to narrow down the problem. > > Best regards, > Goetz. > > > > > > > > > diff -r 3fe33d48aa16 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 16:06:23 2018 +0200 > @@ -73,9 +73,10 @@ > } else { > __ mov(rscratch1, _index->as_jint()); > } > - __ mov(rscratch2, _array->as_pointer_register()); > Runtime1::StubID stub_id; > if (_throw_index_out_of_bounds_exception) { > + assert(_array != NULL, "sanity"); > + __ mov(rscratch2, _array->as_pointer_register()); > stub_id = Runtime1::throw_index_exception_id; > } else { > stub_id = Runtime1::throw_range_check_failed_id; > > > > >> -----Original Message----- >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> Sent: Donnerstag, 19. April 2018 14:26 >> To: Lindenmaier, Goetz >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32-port- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hello Goetz, >> In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just >> need to guard the emission of rscratch2 - you don't use it in one of >> the cases, something like: >> >> if (!_throw_index_out_of_bounds_exception) { >> __ mov(rscratch2, _array->as_pointer_register()); >> } >> >> >> Once I can run the unit tests, I'm seeing failures in your unit test like: >> >> java.lang.AssertionError: expected [trying to access index -5 of an >> array with length 0] but found [trying to access index -5 of an array >> with length -1459548190] >> >> >> BR, >> Stuart >> >> >> On 18 April 2018 at 09:09, Lindenmaier, Goetz >> wrote: >> > Hi, >> > >> > I would like to print a more verbose text on ArrayIndexOutOfBounds >> exception >> > that not only mentions the index, but also the length of the array accessed. >> > See the bug for documentation of the change of the message. >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >> > >> > @aarch/arm people: >> > I edited the aarch/arm files. Could you please verify this is correct? >> > I can not build on these platforms. >> > >> > The code on all the other platforms is tested with all the jtreg and jck tests >> etc. >> > >> > Best regards, >> > Goetz. >> > >> > From david.holmes at oracle.com Fri Apr 20 07:25:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Apr 2018 17:25:19 +1000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5be0f86df2834aa8a881206ba285011e@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> Message-ID: <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Hi Goetz, This is not a file by file review ... On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > I admit my wording is not optimal. src/hotspot/share/oops/typeArrayKlass.cpp Sorry but this is still far too verbose for my tastes. The type of the array is not relevant. For the array copy its okay to indicate src or dst array. But the message should be clear and succinct not prose-like. Plus you have a lot of repetition in the ss.print statements when only one thing is changing. src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp I'm not seeing why the throw_index_out_of_bounds_exception should be tied to whether or not you have an array reference. Certainly I hate seeing the array ref being used as an implicit bool! > It's because I extracted this change from a bigger one. Our message reads like this: > Object [] oa1 = new Object[10] > oa1[12] > "ArrayIndexOutOfBoundsException while trying to load from index 12 of an object array with length 10, loaded from local variable 'oa1'" > ... which seems not optimal, either. But it mentions the type (object), the operation (load, store etc ...) and the variable name. > Naming the array is quite detailed if it is in a complex expression (like returned from a call). > I'll contribute more of this if appreciated, this is a first step. I've never thought this complexity was warranted. We've had a few RFE's of this nature over the years and they have been closed (not necessarily by me I should point out!). > Printing "index N is outside range [0, length-1]" is problematic > for length '0'. I followed the proposal by Roger: > "Index -1 out-of-bounds for length 10." You can easily special-case length 0. But Roger's proposal for consistency with existing messages make sense - not withstanding Andrew's dislike for the hyphens. > I removed the change to ArrayIndexOutOfBoundsException.java. That's good. > I extended the test to cover the exception thrown in arraycopy better The test seems somewhat excessive, and I now see it is because of the more elaborate error messages you have at SAP. But with only the index and the array length of interest here the test can be considerably smaller. The creation tests for ArrayIndexOutOfBoundsException don't seem relevant in this context either. This looks more TCK like. David ----- > and added the elementary type to the message text. This probably > needs improvement in the text, too. There are (currently) these cases: > > bject[] oa1 = new Object[10]; > Object[] oa2 = new Object[5]; > System.arraycopy(oa1, -17, oa2, 0, 5); > "while trying to copy from index -17 of an object array with length 10"); > System.arraycopy(oa1, 2, oa2, -18, 5); > "while trying to copy to index -18 of an object array with length 5"); > System.arraycopy(oa1, 2, oa2, 0, -19); > "while trying to copy a negative range -19 from an object array with length 10 to an object array with length 5"); > System.arraycopy(oa1, 8, oa2, 0, 5); > "while trying to copy from index 13 of an object array with length 10"); > System.arraycopy(oa1, 1, oa2, 0, 7); > "while trying to copy to index 7 of an object array with length 5"); > double[] ta1 = new double[10]; > double[] ta2 = new double[5]; > System.arraycopy(ta1, -17, ta2, 0, 5); > "while trying to copy from index -17 of a doubl array with length 10"); > System.arraycopy(ta1, 2, ta2, -18, 5); > "while trying to copy to index -18 of a double array with length 5"); > System.arraycopy(ta1, 2, ta2, 0, -19); > "while trying to copy a negative range -19 from a double array with length 10 to a double array with length 5"); > System.arraycopy(ta1, 8, ta2, 0, 5); > "while trying to copy from index 13 of a double array with length 10"); > System.arraycopy(ta1, 1, ta2, 0, 7); > "while trying to copy to index 7 of a double array with length 5"); > > Maybe it should say: > Arraycopy source index -1 out-of-bounds for double array of length 10. > Arraycopy target index 10 out-of-bounds for object array of length 10. > Negative range -19 when copying from an object array of length 10 to an object array of length 5. > > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 18. April 2018 10:55 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Adding core-libs-dev as you're changing >> java.lang.ArrayIndexOutOfBoundsException. >> >> I appreciate the intent here but I find the messages excessively >> verbose. The basic error is: >> >> index N is outside range [0, length-1] >> >> David >> >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I would like to print a more verbose text on ArrayIndexOutOfBounds >> exception >>> that not only mentions the index, but also the length of the array accessed. >>> See the bug for documentation of the change of the message. >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>> >>> @aarch/arm people: >>> I edited the aarch/arm files. Could you please verify this is correct? >>> I can not build on these platforms. >>> >>> The code on all the other platforms is tested with all the jtreg and jck tests >> etc. >>> >>> Best regards, >>> Goetz. >>> >>> From goetz.lindenmaier at sap.com Fri Apr 20 10:03:21 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Apr 2018 10:03:21 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Message-ID: <1a27932d85304155b68beb81014298ad@sap.com> Hi David, What about this: java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 out-of-bounds for double[10]. java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 out-of-bounds for object array[10]. java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in arraycopy from int[3] to int[9]. I'll reply to the other points in a comprehensive mail when I know how to put the message. Thanks, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 20. April 2018 09:25 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi Goetz, > > This is not a file by file review ... > > On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > > > I admit my wording is not optimal. > > src/hotspot/share/oops/typeArrayKlass.cpp > > Sorry but this is still far too verbose for my tastes. The type of the > array is not relevant. For the array copy its okay to indicate src or > dst array. But the message should be clear and succinct not prose-like. > Plus you have a lot of repetition in the ss.print statements when only > one thing is changing. > > src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > > I'm not seeing why the throw_index_out_of_bounds_exception should be > tied to whether or not you have an array reference. Certainly I hate > seeing the array ref being used as an implicit bool! > > > It's because I extracted this change from a bigger one. Our message reads > like this: > > Object [] oa1 = new Object[10] > > oa1[12] > > "ArrayIndexOutOfBoundsException while trying to load from index 12 of an > object array with length 10, loaded from local variable 'oa1'" > > ... which seems not optimal, either. But it mentions the type (object), the > operation (load, store etc ...) and the variable name. > > Naming the array is quite detailed if it is in a complex expression (like > returned from a call). > > I'll contribute more of this if appreciated, this is a first step. > > I've never thought this complexity was warranted. We've had a few RFE's > of this nature over the years and they have been closed (not necessarily > by me I should point out!). > > > Printing "index N is outside range [0, length-1]" is problematic > > for length '0'. I followed the proposal by Roger: > > "Index -1 out-of-bounds for length 10." > > You can easily special-case length 0. But Roger's proposal for > consistency with existing messages make sense - not withstanding > Andrew's dislike for the hyphens. > > > I removed the change to ArrayIndexOutOfBoundsException.java. > > That's good. > > > I extended the test to cover the exception thrown in arraycopy better > > The test seems somewhat excessive, and I now see it is because of the > more elaborate error messages you have at SAP. But with only the index > and the array length of interest here the test can be considerably smaller. > > The creation tests for ArrayIndexOutOfBoundsException don't seem > relevant in this context either. This looks more TCK like. > > David > ----- > > > and added the elementary type to the message text. This probably > > needs improvement in the text, too. There are (currently) these cases: > > > > bject[] oa1 = new Object[10]; > > Object[] oa2 = new Object[5]; > > System.arraycopy(oa1, -17, oa2, 0, 5); > > "while trying to copy from index -17 of an object array with length 10"); > > System.arraycopy(oa1, 2, oa2, -18, 5); > > "while trying to copy to index -18 of an object array with length 5"); > > System.arraycopy(oa1, 2, oa2, 0, -19); > > "while trying to copy a negative range -19 from an object array with length > 10 to an object array with length 5"); > > System.arraycopy(oa1, 8, oa2, 0, 5); > > "while trying to copy from index 13 of an object array with length 10"); > > System.arraycopy(oa1, 1, oa2, 0, 7); > > "while trying to copy to index 7 of an object array with length 5"); > > double[] ta1 = new double[10]; > > double[] ta2 = new double[5]; > > System.arraycopy(ta1, -17, ta2, 0, 5); > > "while trying to copy from index -17 of a doubl array with length 10"); > > System.arraycopy(ta1, 2, ta2, -18, 5); > > "while trying to copy to index -18 of a double array with length 5"); > > System.arraycopy(ta1, 2, ta2, 0, -19); > > "while trying to copy a negative range -19 from a double array with length > 10 to a double array with length 5"); > > System.arraycopy(ta1, 8, ta2, 0, 5); > > "while trying to copy from index 13 of a double array with length 10"); > > System.arraycopy(ta1, 1, ta2, 0, 7); > > "while trying to copy to index 7 of a double array with length 5"); > > > > Maybe it should say: > > Arraycopy source index -1 out-of-bounds for double array of length 10. > > Arraycopy target index 10 out-of-bounds for object array of length 10. > > Negative range -19 when copying from an object array of length 10 to an > object array of length 5. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 18. April 2018 10:55 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Adding core-libs-dev as you're changing > >> java.lang.ArrayIndexOutOfBoundsException. > >> > >> I appreciate the intent here but I find the messages excessively > >> verbose. The basic error is: > >> > >> index N is outside range [0, length-1] > >> > >> David > >> > >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >> exception > >>> that not only mentions the index, but also the length of the array > accessed. > >>> See the bug for documentation of the change of the message. > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>> > >>> @aarch/arm people: > >>> I edited the aarch/arm files. Could you please verify this is correct? > >>> I can not build on these platforms. > >>> > >>> The code on all the other platforms is tested with all the jtreg and jck > tests > >> etc. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> From simon at cjnash.com Fri Apr 20 15:16:38 2018 From: simon at cjnash.com (Simon Nash) Date: Fri, 20 Apr 2018 16:16:38 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <1a27932d85304155b68beb81014298ad@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> Message-ID: <5ADA0456.7080607@cjnash.com> Hi Goetz, It should be "out of bounds" without hyphens. Simon On 20/04/2018 11:03, Lindenmaier, Goetz wrote: > Hi David, > > What about this: > java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 out-of-bounds for double[10]. > java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 out-of-bounds for object array[10]. > java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in arraycopy from int[3] to int[9]. > > I'll reply to the other points in a comprehensive mail when I know > how to put the message. > > Thanks, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 20. April 2018 09:25 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi Goetz, >> >> This is not a file by file review ... >> >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>> >>> I admit my wording is not optimal. >> src/hotspot/share/oops/typeArrayKlass.cpp >> >> Sorry but this is still far too verbose for my tastes. The type of the >> array is not relevant. For the array copy its okay to indicate src or >> dst array. But the message should be clear and succinct not prose-like. >> Plus you have a lot of repetition in the ss.print statements when only >> one thing is changing. >> >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >> >> I'm not seeing why the throw_index_out_of_bounds_exception should be >> tied to whether or not you have an array reference. Certainly I hate >> seeing the array ref being used as an implicit bool! >> >>> It's because I extracted this change from a bigger one. Our message reads >> like this: >>> Object [] oa1 = new Object[10] >>> oa1[12] >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of an >> object array with length 10, loaded from local variable 'oa1'" >>> ... which seems not optimal, either. But it mentions the type (object), the >> operation (load, store etc ...) and the variable name. >>> Naming the array is quite detailed if it is in a complex expression (like >> returned from a call). >>> I'll contribute more of this if appreciated, this is a first step. >> I've never thought this complexity was warranted. We've had a few RFE's >> of this nature over the years and they have been closed (not necessarily >> by me I should point out!). >> >>> Printing "index N is outside range [0, length-1]" is problematic >>> for length '0'. I followed the proposal by Roger: >>> "Index -1 out-of-bounds for length 10." >> You can easily special-case length 0. But Roger's proposal for >> consistency with existing messages make sense - not withstanding >> Andrew's dislike for the hyphens. >> >>> I removed the change to ArrayIndexOutOfBoundsException.java. >> That's good. >> >>> I extended the test to cover the exception thrown in arraycopy better >> The test seems somewhat excessive, and I now see it is because of the >> more elaborate error messages you have at SAP. But with only the index >> and the array length of interest here the test can be considerably smaller. >> >> The creation tests for ArrayIndexOutOfBoundsException don't seem >> relevant in this context either. This looks more TCK like. >> >> David >> ----- >> >>> and added the elementary type to the message text. This probably >>> needs improvement in the text, too. There are (currently) these cases: >>> >>> bject[] oa1 = new Object[10]; >>> Object[] oa2 = new Object[5]; >>> System.arraycopy(oa1, -17, oa2, 0, 5); >>> "while trying to copy from index -17 of an object array with length 10"); >>> System.arraycopy(oa1, 2, oa2, -18, 5); >>> "while trying to copy to index -18 of an object array with length 5"); >>> System.arraycopy(oa1, 2, oa2, 0, -19); >>> "while trying to copy a negative range -19 from an object array with length >> 10 to an object array with length 5"); >>> System.arraycopy(oa1, 8, oa2, 0, 5); >>> "while trying to copy from index 13 of an object array with length 10"); >>> System.arraycopy(oa1, 1, oa2, 0, 7); >>> "while trying to copy to index 7 of an object array with length 5"); >>> double[] ta1 = new double[10]; >>> double[] ta2 = new double[5]; >>> System.arraycopy(ta1, -17, ta2, 0, 5); >>> "while trying to copy from index -17 of a doubl array with length 10"); >>> System.arraycopy(ta1, 2, ta2, -18, 5); >>> "while trying to copy to index -18 of a double array with length 5"); >>> System.arraycopy(ta1, 2, ta2, 0, -19); >>> "while trying to copy a negative range -19 from a double array with length >> 10 to a double array with length 5"); >>> System.arraycopy(ta1, 8, ta2, 0, 5); >>> "while trying to copy from index 13 of a double array with length 10"); >>> System.arraycopy(ta1, 1, ta2, 0, 7); >>> "while trying to copy to index 7 of a double array with length 5"); >>> >>> Maybe it should say: >>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>> Negative range -19 when copying from an object array of length 10 to an >> object array of length 5. >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 18. April 2018 10:55 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Adding core-libs-dev as you're changing >>>> java.lang.ArrayIndexOutOfBoundsException. >>>> >>>> I appreciate the intent here but I find the messages excessively >>>> verbose. The basic error is: >>>> >>>> index N is outside range [0, length-1] >>>> >>>> David >>>> >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>> exception >>>>> that not only mentions the index, but also the length of the array >> accessed. >>>>> See the bug for documentation of the change of the message. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>> >>>>> @aarch/arm people: >>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>> I can not build on these platforms. >>>>> >>>>> The code on all the other platforms is tested with all the jtreg and jck >> tests >>>> etc. >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From aph at redhat.com Fri Apr 20 15:23:50 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Apr 2018 16:23:50 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5ADA0456.7080607@cjnash.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> <5ADA0456.7080607@cjnash.com> Message-ID: On 04/20/2018 04:16 PM, Simon Nash wrote: > It should be "out of bounds" without hyphens. "out of bounds" should not be in the string. We know it's an IndexOutOfBounds exception. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Mon Apr 23 03:33:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Apr 2018 13:33:33 +1000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <1a27932d85304155b68beb81014298ad@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> Message-ID: On 20/04/2018 8:03 PM, Lindenmaier, Goetz wrote: > Hi David, > > What about this: > java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 out-of-bounds for double[10]. > java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 out-of-bounds for object array[10]. > java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in arraycopy from int[3] to int[9]. I still don't like the array type information - it's not relevant to the error IMHO. That aside, for the array copy cases I'd go for something like: arraycopy src index -1 out of bounds for double[10] arraycopy dest index -1 out of bounds for double[10] arraycopy end src index 11 out of bounds for double[10] arraycopy end dest index 11 out of bounds for double[10] arraycopy length -19 is negative In the final case the array lengths are not relevant. > I'll reply to the other points in a comprehensive mail when I know > how to put the message. I don't oppose additional useful information in exception messages, but if it not directly relevant it just makes the error message harder to decipher IMO. I also don't want to pay additional runtime costs just to make an exception message a little bit clearer. Thanks, David > Thanks, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 20. April 2018 09:25 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi Goetz, >> >> This is not a file by file review ... >> >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>> >>> I admit my wording is not optimal. >> >> src/hotspot/share/oops/typeArrayKlass.cpp >> >> Sorry but this is still far too verbose for my tastes. The type of the >> array is not relevant. For the array copy its okay to indicate src or >> dst array. But the message should be clear and succinct not prose-like. >> Plus you have a lot of repetition in the ss.print statements when only >> one thing is changing. >> >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >> >> I'm not seeing why the throw_index_out_of_bounds_exception should be >> tied to whether or not you have an array reference. Certainly I hate >> seeing the array ref being used as an implicit bool! >> >>> It's because I extracted this change from a bigger one. Our message reads >> like this: >>> Object [] oa1 = new Object[10] >>> oa1[12] >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of an >> object array with length 10, loaded from local variable 'oa1'" >>> ... which seems not optimal, either. But it mentions the type (object), the >> operation (load, store etc ...) and the variable name. >>> Naming the array is quite detailed if it is in a complex expression (like >> returned from a call). >>> I'll contribute more of this if appreciated, this is a first step. >> >> I've never thought this complexity was warranted. We've had a few RFE's >> of this nature over the years and they have been closed (not necessarily >> by me I should point out!). >> >>> Printing "index N is outside range [0, length-1]" is problematic >>> for length '0'. I followed the proposal by Roger: >>> "Index -1 out-of-bounds for length 10." >> >> You can easily special-case length 0. But Roger's proposal for >> consistency with existing messages make sense - not withstanding >> Andrew's dislike for the hyphens. >> >>> I removed the change to ArrayIndexOutOfBoundsException.java. >> >> That's good. >> >>> I extended the test to cover the exception thrown in arraycopy better >> >> The test seems somewhat excessive, and I now see it is because of the >> more elaborate error messages you have at SAP. But with only the index >> and the array length of interest here the test can be considerably smaller. >> >> The creation tests for ArrayIndexOutOfBoundsException don't seem >> relevant in this context either. This looks more TCK like. >> >> David >> ----- >> >>> and added the elementary type to the message text. This probably >>> needs improvement in the text, too. There are (currently) these cases: >>> >>> bject[] oa1 = new Object[10]; >>> Object[] oa2 = new Object[5]; >>> System.arraycopy(oa1, -17, oa2, 0, 5); >>> "while trying to copy from index -17 of an object array with length 10"); >>> System.arraycopy(oa1, 2, oa2, -18, 5); >>> "while trying to copy to index -18 of an object array with length 5"); >>> System.arraycopy(oa1, 2, oa2, 0, -19); >>> "while trying to copy a negative range -19 from an object array with length >> 10 to an object array with length 5"); >>> System.arraycopy(oa1, 8, oa2, 0, 5); >>> "while trying to copy from index 13 of an object array with length 10"); >>> System.arraycopy(oa1, 1, oa2, 0, 7); >>> "while trying to copy to index 7 of an object array with length 5"); >>> double[] ta1 = new double[10]; >>> double[] ta2 = new double[5]; >>> System.arraycopy(ta1, -17, ta2, 0, 5); >>> "while trying to copy from index -17 of a doubl array with length 10"); >>> System.arraycopy(ta1, 2, ta2, -18, 5); >>> "while trying to copy to index -18 of a double array with length 5"); >>> System.arraycopy(ta1, 2, ta2, 0, -19); >>> "while trying to copy a negative range -19 from a double array with length >> 10 to a double array with length 5"); >>> System.arraycopy(ta1, 8, ta2, 0, 5); >>> "while trying to copy from index 13 of a double array with length 10"); >>> System.arraycopy(ta1, 1, ta2, 0, 7); >>> "while trying to copy to index 7 of a double array with length 5"); >>> >>> Maybe it should say: >>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>> Negative range -19 when copying from an object array of length 10 to an >> object array of length 5. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 18. April 2018 10:55 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Adding core-libs-dev as you're changing >>>> java.lang.ArrayIndexOutOfBoundsException. >>>> >>>> I appreciate the intent here but I find the messages excessively >>>> verbose. The basic error is: >>>> >>>> index N is outside range [0, length-1] >>>> >>>> David >>>> >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>> exception >>>>> that not only mentions the index, but also the length of the array >> accessed. >>>>> See the bug for documentation of the change of the message. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>> >>>>> @aarch/arm people: >>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>> I can not build on these platforms. >>>>> >>>>> The code on all the other platforms is tested with all the jtreg and jck >> tests >>>> etc. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From goetz.lindenmaier at sap.com Mon Apr 23 07:08:03 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Apr 2018 07:08:03 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> Message-ID: <2dfac30b29f44974a72cb26d9dfb15fc@sap.com> Hi, > I still don't like the array type information - it's not relevant to the > error IMHO. > > That aside, for the array copy cases I'd go for something like: > > arraycopy src index -1 out of bounds for double[10] > arraycopy dest index -1 out of bounds for double[10] > arraycopy end src index 11 out of bounds for double[10] > arraycopy end dest index 11 out of bounds for double[10] It's a good idea to point out it's the end of the region to copy. But I would find "last src index" better to understand than "end src index": "last arraycopy src index 11 out of bounds for double[10]" > arraycopy length -19 is negative > > In the final case the array lengths are not relevant. I think they might help in case the length computation depends on the array lengths, which is quite likely the case. But I'll leave it out. > > I'll reply to the other points in a comprehensive mail when I know > > how to put the message. ... these all are not related to the wording of the message. > > I don't oppose additional useful information in exception messages, but > if it not directly relevant it just makes the error message harder to > decipher IMO. SAP JVM tries to give all information useful to track down the cause. In many situations the printed information might be superfluous, but in this one critical situation you will be very happy to have it. SAP builds 'real' software on Java, not just 100 line jtreg tests ... But the message should stay clear. Therefore I also don't like the 1-sentence rule you sometimes mention. Several sentences can give structure to distinguish root cause information and additional information. Not relevant here currently, though. > I also don't want to pay additional runtime costs just to > make an exception message a little bit clearer. Yes, especially it should not impose any cost on the case without exception. Best regards, Goetz. > Thanks, > David > > > Thanks, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 20. April 2018 09:25 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi Goetz, > >> > >> This is not a file by file review ... > >> > >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >>> > >>> I admit my wording is not optimal. > >> > >> src/hotspot/share/oops/typeArrayKlass.cpp > >> > >> Sorry but this is still far too verbose for my tastes. The type of the > >> array is not relevant. For the array copy its okay to indicate src or > >> dst array. But the message should be clear and succinct not prose-like. > >> Plus you have a lot of repetition in the ss.print statements when only > >> one thing is changing. > >> > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > >> > >> I'm not seeing why the throw_index_out_of_bounds_exception should > be > >> tied to whether or not you have an array reference. Certainly I hate > >> seeing the array ref being used as an implicit bool! > >> > >>> It's because I extracted this change from a bigger one. Our message > reads > >> like this: > >>> Object [] oa1 = new Object[10] > >>> oa1[12] > >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of > an > >> object array with length 10, loaded from local variable 'oa1'" > >>> ... which seems not optimal, either. But it mentions the type (object), > the > >> operation (load, store etc ...) and the variable name. > >>> Naming the array is quite detailed if it is in a complex expression (like > >> returned from a call). > >>> I'll contribute more of this if appreciated, this is a first step. > >> > >> I've never thought this complexity was warranted. We've had a few RFE's > >> of this nature over the years and they have been closed (not necessarily > >> by me I should point out!). > >> > >>> Printing "index N is outside range [0, length-1]" is problematic > >>> for length '0'. I followed the proposal by Roger: > >>> "Index -1 out-of-bounds for length 10." > >> > >> You can easily special-case length 0. But Roger's proposal for > >> consistency with existing messages make sense - not withstanding > >> Andrew's dislike for the hyphens. > >> > >>> I removed the change to ArrayIndexOutOfBoundsException.java. > >> > >> That's good. > >> > >>> I extended the test to cover the exception thrown in arraycopy better > >> > >> The test seems somewhat excessive, and I now see it is because of the > >> more elaborate error messages you have at SAP. But with only the index > >> and the array length of interest here the test can be considerably smaller. > >> > >> The creation tests for ArrayIndexOutOfBoundsException don't seem > >> relevant in this context either. This looks more TCK like. > >> > >> David > >> ----- > >> > >>> and added the elementary type to the message text. This probably > >>> needs improvement in the text, too. There are (currently) these cases: > >>> > >>> bject[] oa1 = new Object[10]; > >>> Object[] oa2 = new Object[5]; > >>> System.arraycopy(oa1, -17, oa2, 0, 5); > >>> "while trying to copy from index -17 of an object array with length 10"); > >>> System.arraycopy(oa1, 2, oa2, -18, 5); > >>> "while trying to copy to index -18 of an object array with length 5"); > >>> System.arraycopy(oa1, 2, oa2, 0, -19); > >>> "while trying to copy a negative range -19 from an object array with > length > >> 10 to an object array with length 5"); > >>> System.arraycopy(oa1, 8, oa2, 0, 5); > >>> "while trying to copy from index 13 of an object array with length 10"); > >>> System.arraycopy(oa1, 1, oa2, 0, 7); > >>> "while trying to copy to index 7 of an object array with length 5"); > >>> double[] ta1 = new double[10]; > >>> double[] ta2 = new double[5]; > >>> System.arraycopy(ta1, -17, ta2, 0, 5); > >>> "while trying to copy from index -17 of a doubl array with length 10"); > >>> System.arraycopy(ta1, 2, ta2, -18, 5); > >>> "while trying to copy to index -18 of a double array with length 5"); > >>> System.arraycopy(ta1, 2, ta2, 0, -19); > >>> "while trying to copy a negative range -19 from a double array with > length > >> 10 to a double array with length 5"); > >>> System.arraycopy(ta1, 8, ta2, 0, 5); > >>> "while trying to copy from index 13 of a double array with length 10"); > >>> System.arraycopy(ta1, 1, ta2, 0, 7); > >>> "while trying to copy to index 7 of a double array with length 5"); > >>> > >>> Maybe it should say: > >>> Arraycopy source index -1 out-of-bounds for double array of length 10. > >>> Arraycopy target index 10 out-of-bounds for object array of length 10. > >>> Negative range -19 when copying from an object array of length 10 to an > >> object array of length 5. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 18. April 2018 10:55 > >>>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > >> aarch64- > >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; > core- > >> libs- > >>>> dev Libs > >>>> Subject: Re: RFR(M): 8201593: Print array length in > >>>> ArrayIndexOutOfBoundsException. > >>>> > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>> exception > >>>>> that not only mentions the index, but also the length of the array > >> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg and jck > >> tests > >>>> etc. > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From goetz.lindenmaier at sap.com Mon Apr 23 07:13:25 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Apr 2018 07:13:25 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5ADA0456.7080607@cjnash.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> <5ADA0456.7080607@cjnash.com> Message-ID: Hi Simon, I chose hyphens because they are used in other AIOOB messages, too. But others (including me) seem not to like them either, so I'll leave them out. Best regards, Goetz. > -----Original Message----- > From: Simon Nash [mailto:simon at cjnash.com] > Sent: Freitag, 20. April 2018 17:17 > To: Lindenmaier, Goetz > Cc: David Holmes ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi Goetz, > It should be "out of bounds" without hyphens. > > Simon > > On 20/04/2018 11:03, Lindenmaier, Goetz wrote: > > Hi David, > > > > What about this: > > java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 > out-of-bounds for double[10]. > > java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 > out-of-bounds for object array[10]. > > java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in > arraycopy from int[3] to int[9]. > > > > I'll reply to the other points in a comprehensive mail when I know > > how to put the message. > > > > Thanks, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 20. April 2018 09:25 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi Goetz, > >> > >> This is not a file by file review ... > >> > >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >>> > >>> I admit my wording is not optimal. > >> src/hotspot/share/oops/typeArrayKlass.cpp > >> > >> Sorry but this is still far too verbose for my tastes. The type of the > >> array is not relevant. For the array copy its okay to indicate src or > >> dst array. But the message should be clear and succinct not prose-like. > >> Plus you have a lot of repetition in the ss.print statements when only > >> one thing is changing. > >> > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > >> > >> I'm not seeing why the throw_index_out_of_bounds_exception should > be > >> tied to whether or not you have an array reference. Certainly I hate > >> seeing the array ref being used as an implicit bool! > >> > >>> It's because I extracted this change from a bigger one. Our message > reads > >> like this: > >>> Object [] oa1 = new Object[10] > >>> oa1[12] > >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of > an > >> object array with length 10, loaded from local variable 'oa1'" > >>> ... which seems not optimal, either. But it mentions the type (object), > the > >> operation (load, store etc ...) and the variable name. > >>> Naming the array is quite detailed if it is in a complex expression (like > >> returned from a call). > >>> I'll contribute more of this if appreciated, this is a first step. > >> I've never thought this complexity was warranted. We've had a few RFE's > >> of this nature over the years and they have been closed (not necessarily > >> by me I should point out!). > >> > >>> Printing "index N is outside range [0, length-1]" is problematic > >>> for length '0'. I followed the proposal by Roger: > >>> "Index -1 out-of-bounds for length 10." > >> You can easily special-case length 0. But Roger's proposal for > >> consistency with existing messages make sense - not withstanding > >> Andrew's dislike for the hyphens. > >> > >>> I removed the change to ArrayIndexOutOfBoundsException.java. > >> That's good. > >> > >>> I extended the test to cover the exception thrown in arraycopy better > >> The test seems somewhat excessive, and I now see it is because of the > >> more elaborate error messages you have at SAP. But with only the index > >> and the array length of interest here the test can be considerably smaller. > >> > >> The creation tests for ArrayIndexOutOfBoundsException don't seem > >> relevant in this context either. This looks more TCK like. > >> > >> David > >> ----- > >> > >>> and added the elementary type to the message text. This probably > >>> needs improvement in the text, too. There are (currently) these cases: > >>> > >>> bject[] oa1 = new Object[10]; > >>> Object[] oa2 = new Object[5]; > >>> System.arraycopy(oa1, -17, oa2, 0, 5); > >>> "while trying to copy from index -17 of an object array with length 10"); > >>> System.arraycopy(oa1, 2, oa2, -18, 5); > >>> "while trying to copy to index -18 of an object array with length 5"); > >>> System.arraycopy(oa1, 2, oa2, 0, -19); > >>> "while trying to copy a negative range -19 from an object array with > length > >> 10 to an object array with length 5"); > >>> System.arraycopy(oa1, 8, oa2, 0, 5); > >>> "while trying to copy from index 13 of an object array with length 10"); > >>> System.arraycopy(oa1, 1, oa2, 0, 7); > >>> "while trying to copy to index 7 of an object array with length 5"); > >>> double[] ta1 = new double[10]; > >>> double[] ta2 = new double[5]; > >>> System.arraycopy(ta1, -17, ta2, 0, 5); > >>> "while trying to copy from index -17 of a doubl array with length 10"); > >>> System.arraycopy(ta1, 2, ta2, -18, 5); > >>> "while trying to copy to index -18 of a double array with length 5"); > >>> System.arraycopy(ta1, 2, ta2, 0, -19); > >>> "while trying to copy a negative range -19 from a double array with > length > >> 10 to a double array with length 5"); > >>> System.arraycopy(ta1, 8, ta2, 0, 5); > >>> "while trying to copy from index 13 of a double array with length 10"); > >>> System.arraycopy(ta1, 1, ta2, 0, 7); > >>> "while trying to copy to index 7 of a double array with length 5"); > >>> > >>> Maybe it should say: > >>> Arraycopy source index -1 out-of-bounds for double array of length 10. > >>> Arraycopy target index 10 out-of-bounds for object array of length 10. > >>> Negative range -19 when copying from an object array of length 10 to an > >> object array of length 5. > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 18. April 2018 10:55 > >>>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > >> aarch64- > >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; > core- > >> libs- > >>>> dev Libs > >>>> Subject: Re: RFR(M): 8201593: Print array length in > >>>> ArrayIndexOutOfBoundsException. > >>>> > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>> exception > >>>>> that not only mentions the index, but also the length of the array > >> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg and jck > >> tests > >>>> etc. > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From david.holmes at oracle.com Mon Apr 23 07:14:09 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Apr 2018 17:14:09 +1000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <2dfac30b29f44974a72cb26d9dfb15fc@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> <2dfac30b29f44974a72cb26d9dfb15fc@sap.com> Message-ID: <81c38514-e6a7-208c-6f82-5b342d087d42@oracle.com> On 23/04/2018 5:08 PM, Lindenmaier, Goetz wrote: > Hi, > >> I still don't like the array type information - it's not relevant to the >> error IMHO. >> >> That aside, for the array copy cases I'd go for something like: >> >> arraycopy src index -1 out of bounds for double[10] >> arraycopy dest index -1 out of bounds for double[10] >> arraycopy end src index 11 out of bounds for double[10] >> arraycopy end dest index 11 out of bounds for double[10] > It's a good idea to point out it's the end of the region to copy. > But I would find "last src index" better to understand than > "end src index": Sure - end/last/final whatever you prefer. > "last arraycopy src index 11 out of bounds for double[10]" I'd prefer to see "arraycopy" always come first to show clearly these are specific to arraycopy. Even "arraycopy: ...". >> arraycopy length -19 is negative >> >> In the final case the array lengths are not relevant. > I think they might help in case the length computation depends on the > array lengths, which is quite likely the case. But I'll leave it out. Happy to let others give opinions. David ----- >>> I'll reply to the other points in a comprehensive mail when I know >>> how to put the message. > ... these all are not related to the wording of the message. >> >> I don't oppose additional useful information in exception messages, but >> if it not directly relevant it just makes the error message harder to >> decipher IMO. > SAP JVM tries to give all information useful to track down the cause. > In many situations the printed information might be superfluous, but > in this one critical situation you will be very happy to have it. SAP builds > 'real' software on Java, not just 100 line jtreg tests ... > But the message should stay clear. Therefore I also don't like the > 1-sentence rule you sometimes mention. Several sentences can give > structure to distinguish root cause information and additional information. > Not relevant here currently, though. > >> I also don't want to pay additional runtime costs just to >> make an exception message a little bit clearer. > Yes, especially it should not impose any cost on the case without exception. > > Best regards, > Goetz. > > >> Thanks, >> David >> >>> Thanks, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 20. April 2018 09:25 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Hi Goetz, >>>> >>>> This is not a file by file review ... >>>> >>>> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>>>> >>>>> I admit my wording is not optimal. >>>> >>>> src/hotspot/share/oops/typeArrayKlass.cpp >>>> >>>> Sorry but this is still far too verbose for my tastes. The type of the >>>> array is not relevant. For the array copy its okay to indicate src or >>>> dst array. But the message should be clear and succinct not prose-like. >>>> Plus you have a lot of repetition in the ss.print statements when only >>>> one thing is changing. >>>> >>>> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >>>> >>>> I'm not seeing why the throw_index_out_of_bounds_exception should >> be >>>> tied to whether or not you have an array reference. Certainly I hate >>>> seeing the array ref being used as an implicit bool! >>>> >>>>> It's because I extracted this change from a bigger one. Our message >> reads >>>> like this: >>>>> Object [] oa1 = new Object[10] >>>>> oa1[12] >>>>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of >> an >>>> object array with length 10, loaded from local variable 'oa1'" >>>>> ... which seems not optimal, either. But it mentions the type (object), >> the >>>> operation (load, store etc ...) and the variable name. >>>>> Naming the array is quite detailed if it is in a complex expression (like >>>> returned from a call). >>>>> I'll contribute more of this if appreciated, this is a first step. >>>> >>>> I've never thought this complexity was warranted. We've had a few RFE's >>>> of this nature over the years and they have been closed (not necessarily >>>> by me I should point out!). >>>> >>>>> Printing "index N is outside range [0, length-1]" is problematic >>>>> for length '0'. I followed the proposal by Roger: >>>>> "Index -1 out-of-bounds for length 10." >>>> >>>> You can easily special-case length 0. But Roger's proposal for >>>> consistency with existing messages make sense - not withstanding >>>> Andrew's dislike for the hyphens. >>>> >>>>> I removed the change to ArrayIndexOutOfBoundsException.java. >>>> >>>> That's good. >>>> >>>>> I extended the test to cover the exception thrown in arraycopy better >>>> >>>> The test seems somewhat excessive, and I now see it is because of the >>>> more elaborate error messages you have at SAP. But with only the index >>>> and the array length of interest here the test can be considerably smaller. >>>> >>>> The creation tests for ArrayIndexOutOfBoundsException don't seem >>>> relevant in this context either. This looks more TCK like. >>>> >>>> David >>>> ----- >>>> >>>>> and added the elementary type to the message text. This probably >>>>> needs improvement in the text, too. There are (currently) these cases: >>>>> >>>>> bject[] oa1 = new Object[10]; >>>>> Object[] oa2 = new Object[5]; >>>>> System.arraycopy(oa1, -17, oa2, 0, 5); >>>>> "while trying to copy from index -17 of an object array with length 10"); >>>>> System.arraycopy(oa1, 2, oa2, -18, 5); >>>>> "while trying to copy to index -18 of an object array with length 5"); >>>>> System.arraycopy(oa1, 2, oa2, 0, -19); >>>>> "while trying to copy a negative range -19 from an object array with >> length >>>> 10 to an object array with length 5"); >>>>> System.arraycopy(oa1, 8, oa2, 0, 5); >>>>> "while trying to copy from index 13 of an object array with length 10"); >>>>> System.arraycopy(oa1, 1, oa2, 0, 7); >>>>> "while trying to copy to index 7 of an object array with length 5"); >>>>> double[] ta1 = new double[10]; >>>>> double[] ta2 = new double[5]; >>>>> System.arraycopy(ta1, -17, ta2, 0, 5); >>>>> "while trying to copy from index -17 of a doubl array with length 10"); >>>>> System.arraycopy(ta1, 2, ta2, -18, 5); >>>>> "while trying to copy to index -18 of a double array with length 5"); >>>>> System.arraycopy(ta1, 2, ta2, 0, -19); >>>>> "while trying to copy a negative range -19 from a double array with >> length >>>> 10 to a double array with length 5"); >>>>> System.arraycopy(ta1, 8, ta2, 0, 5); >>>>> "while trying to copy from index 13 of a double array with length 10"); >>>>> System.arraycopy(ta1, 1, ta2, 0, 7); >>>>> "while trying to copy to index 7 of a double array with length 5"); >>>>> >>>>> Maybe it should say: >>>>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>>>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>>>> Negative range -19 when copying from an object array of length 10 to an >>>> object array of length 5. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 18. April 2018 10:55 >>>>>> To: Lindenmaier, Goetz ; hotspot- >> runtime- >>>>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >>>> aarch64- >>>>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; >> core- >>>> libs- >>>>>> dev Libs >>>>>> Subject: Re: RFR(M): 8201593: Print array length in >>>>>> ArrayIndexOutOfBoundsException. >>>>>> >>>>>> Adding core-libs-dev as you're changing >>>>>> java.lang.ArrayIndexOutOfBoundsException. >>>>>> >>>>>> I appreciate the intent here but I find the messages excessively >>>>>> verbose. The basic error is: >>>>>> >>>>>> index N is outside range [0, length-1] >>>>>> >>>>>> David >>>>>> >>>>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>>>> exception >>>>>>> that not only mentions the index, but also the length of the array >>>> accessed. >>>>>>> See the bug for documentation of the change of the message. >>>>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>>>> >>>>>>> @aarch/arm people: >>>>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>>>> I can not build on these platforms. >>>>>>> >>>>>>> The code on all the other platforms is tested with all the jtreg and jck >>>> tests >>>>>> etc. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> From goetz.lindenmaier at sap.com Mon Apr 23 07:14:37 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Apr 2018 07:14:37 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> <5ADA0456.7080607@cjnash.com> Message-ID: Hi Andrew, > We know it's an IndexOutOfBounds No, the AIOOB is not always thrown because an index is out of bounds. See the negative length case. Best regards, Goetz. > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] > Sent: Freitag, 20. April 2018 17:24 > To: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > On 04/20/2018 04:16 PM, Simon Nash wrote: > > It should be "out of bounds" without hyphens. > > > "out of bounds" should not be in the string. We know it's an > IndexOutOfBounds > exception. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue Apr 24 03:35:41 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 24 Apr 2018 04:35:41 +0100 Subject: [aarch64-port-dev ] [RFR] 8u171 Update Message-ID: Hi, OpenJDK 8 was recently updated with a security update, u171. Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u171-b10. http://cr.openjdk.java.net/~andrew/aarch64-8/u171/ The Shenandoah merge is: http://cr.openjdk.java.net/~andrew/aarch64-8/u171/hotspot/shenandoah.merge.b10 Changes in aarch64-jdk8u171-b10: - S8054213: Class name repeated in output of Type.toString() - S8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available - S8150530: Improve javax.crypto.BadPaddingException messages - S8153955: increase java.util.logging.FileHandler MAX_LOCKS limit - S8169080: Improve documentation examples for crypto applications - S8175075: Add 3DES to the default disabled algorithm security property - S8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location - S8180881: Better packaging of deserialization - S8182362: Update CipherOutputStream Usage - S8183032: Upgrade to LittleCMS 2.9 - S8186032: Disable XML Signatures signed with EC keys less than 224 bits - S8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class - S8187496: Possible memory leak in java.apple.security.KeychainStore.addItemToKeychain - S8189123: More consistent classloading - S8189789: tomcat gzip-compressed response bodies appear to be broken in update 151 - S8189851: [TESTBUG] runtime/RedefineTests/RedefineInterfaceCall.java fails - S8189969: Manifest better manifest entries - S8189977: Improve permission portability - S8189981: Improve queuing portability - S8189985: Improve tabular data portability - S8189989: Improve container portability - S8189993: Improve document portability - S8189997: Enhance keystore mechanisms - S8190478: Improved interface method selection - S8190877: Better handling of abstract classes - S8191358: Restore TSA certificate expiration check - S8191696: Better mouse positioning - S8191909: Nightly failures in nashorn suite - S8192025: Less referential references - S8192030: Better MTSchema support - S8192757: Improve stub classes implementation - S8192789: Avoid using AtomicReference in sun.security.provider.PolicyFile - S8193409: Improve AES supporting classes - S8193414: Improvements in MethodType lookups - S8193833: Better RMI connection support - S8194259: keytool error: java.io.IOException: Invalid secret key format - S8195837: (tz) Upgrade time-zone data to tzdata2018c - S8196952: Bad primeCertainty value setting in DSAParameterGenerator - S8197030: Perf regression on all platforms with 8u171-b03 - early lambda use - S8198494: 8u171 and 8u172 - Build failure on non-SE Linux Platforms - S8198662: Incompatible internal API change in JDK8u161: signature of method exportObject() - S8198963: Fix new rmi property name - S8199001: [TESTBUG] RMIConnectionFilterTest.java test fails in compilation Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Tue Apr 24 07:09:11 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Apr 2018 09:09:11 +0200 Subject: [aarch64-port-dev ] [RFR] 8u171 Update In-Reply-To: References: Message-ID: <898a7b4a-c6c3-6713-3712-61f927c1815f@redhat.com> On 04/24/2018 05:35 AM, Andrew Hughes wrote: > Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u171-b10. > http://cr.openjdk.java.net/~andrew/aarch64-8/u171/ corba looks ok. hotspot looks ok. jaxp looks ok. jdk looks ok. jaxws looks ok. langtools looks ok. nashorn looks ok. All good. > The Shenandoah merge is: > http://cr.openjdk.java.net/~andrew/aarch64-8/u171/hotspot/shenandoah.merge.b10 Missing bits in cpp/fixup_cloned_reference: *) "if (UseG1GC)" should be "if (UseG1GC || UseShenandoahGC)" -- Shenandoah/8u piggybacks on G1 on this path *) oopDesc::equals is missing, Shenandoah needs it for correctness: "(java_lang_ref_Reference::queue(clone) == java_lang_ref_ReferenceQueue::ENQUEUED_queue())" should be: "(oopDesc::equals(java_lang_ref_Reference::queue(clone), java_lang_ref_ReferenceQueue::ENQUEUED_queue())))" I can fix them after the merge. Thanks, -Aleksey From goetz.lindenmaier at sap.com Tue Apr 24 10:44:48 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Apr 2018 10:44:48 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> Hi Stuart, could you track down the remaining issue? Best regards, Goetz. > -----Original Message----- > From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > Sent: Donnerstag, 19. April 2018 17:09 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32-port- > dev at openjdk.java.net > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi, > I'm trying to work through what's going on here. With C1 not > crashing, I'll check the behaviour of the interpreter and C2. I'm > doing explicitly with -Xint, etc. WIth -Xint I definitely get the > error. > > You have the condition the wrong way round - > _throw_index_out_of_bounds_exception is true when array is NULL. > > > BR, > Stuart > > > On 19 April 2018 at 15:36, Lindenmaier, Goetz > wrote: > > Hi Stuart, > > > > thanks a lot for helping out here. > > I added below patch to my latest webrev (replaced it in-place): > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > > > The remaining problem looks like the array argument does not > > reach the method that prints the message properly. > > Did I get a register wrong? > > Did I use a wrong argument register, or does the untangling > > of registers in overwrite something? > > Is it correct to use mov and not movw in > templateInterpreterGenerator_aarch64.cpp? > > Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" here is > stupid, > > it seems to cause unnecessary register moves. But it's similar on all > platforms.) > > > > The test runs several times, assuring it's C1, C2 and Xint. > > This should help you to narrow down the problem. > > > > Best regards, > > Goetz. > > > > > > > > > > > > > > > > > > diff -r 3fe33d48aa16 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp > > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 > 15:17:20 2018 +0200 > > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 > 16:06:23 2018 +0200 > > @@ -73,9 +73,10 @@ > > } else { > > __ mov(rscratch1, _index->as_jint()); > > } > > - __ mov(rscratch2, _array->as_pointer_register()); > > Runtime1::StubID stub_id; > > if (_throw_index_out_of_bounds_exception) { > > + assert(_array != NULL, "sanity"); > > + __ mov(rscratch2, _array->as_pointer_register()); > > stub_id = Runtime1::throw_index_exception_id; > > } else { > > stub_id = Runtime1::throw_range_check_failed_id; > > > > > > > > > >> -----Original Message----- > >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > >> Sent: Donnerstag, 19. April 2018 14:26 > >> To: Lindenmaier, Goetz > >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- > >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32- > port- > >> dev at openjdk.java.net > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hello Goetz, > >> In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just > >> need to guard the emission of rscratch2 - you don't use it in one of > >> the cases, something like: > >> > >> if (!_throw_index_out_of_bounds_exception) { > >> __ mov(rscratch2, _array->as_pointer_register()); > >> } > >> > >> > >> Once I can run the unit tests, I'm seeing failures in your unit test like: > >> > >> java.lang.AssertionError: expected [trying to access index -5 of an > >> array with length 0] but found [trying to access index -5 of an array > >> with length -1459548190] > >> > >> > >> BR, > >> Stuart > >> > >> > >> On 18 April 2018 at 09:09, Lindenmaier, Goetz > > >> wrote: > >> > Hi, > >> > > >> > I would like to print a more verbose text on ArrayIndexOutOfBounds > >> exception > >> > that not only mentions the index, but also the length of the array > accessed. > >> > See the bug for documentation of the change of the message. > >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >> > > >> > @aarch/arm people: > >> > I edited the aarch/arm files. Could you please verify this is correct? > >> > I can not build on these platforms. > >> > > >> > The code on all the other platforms is tested with all the jtreg and jck > tests > >> etc. > >> > > >> > Best regards, > >> > Goetz. > >> > > >> > From stuart.monteith at linaro.org Tue Apr 24 12:27:58 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 24 Apr 2018 13:27:58 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> Message-ID: Hello Goetz, It appears that it is just C1 that exhibits the problem - there has been a delay as I've been investigating a hang in Java JDK running some of my automation. I'll try and track down the issue. Otherwise, I do like the principle of the patch. BR, Stuart On 24 April 2018 at 11:44, Lindenmaier, Goetz wrote: > Hi Stuart, > > could you track down the remaining issue? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> Sent: Donnerstag, 19. April 2018 17:09 >> To: Lindenmaier, Goetz >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32-port- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi, >> I'm trying to work through what's going on here. With C1 not >> crashing, I'll check the behaviour of the interpreter and C2. I'm >> doing explicitly with -Xint, etc. WIth -Xint I definitely get the >> error. >> >> You have the condition the wrong way round - >> _throw_index_out_of_bounds_exception is true when array is NULL. >> >> >> BR, >> Stuart >> >> >> On 19 April 2018 at 15:36, Lindenmaier, Goetz >> wrote: >> > Hi Stuart, >> > >> > thanks a lot for helping out here. >> > I added below patch to my latest webrev (replaced it in-place): >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >> > >> > The remaining problem looks like the array argument does not >> > reach the method that prints the message properly. >> > Did I get a register wrong? >> > Did I use a wrong argument register, or does the untangling >> > of registers in overwrite something? >> > Is it correct to use mov and not movw in >> templateInterpreterGenerator_aarch64.cpp? >> > Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" here is >> stupid, >> > it seems to cause unnecessary register moves. But it's similar on all >> platforms.) >> > >> > The test runs several times, assuring it's C1, C2 and Xint. >> > This should help you to narrow down the problem. >> > >> > Best regards, >> > Goetz. >> > >> > >> > >> > >> > >> > >> > >> > >> > diff -r 3fe33d48aa16 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp >> > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 >> 15:17:20 2018 +0200 >> > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 >> 16:06:23 2018 +0200 >> > @@ -73,9 +73,10 @@ >> > } else { >> > __ mov(rscratch1, _index->as_jint()); >> > } >> > - __ mov(rscratch2, _array->as_pointer_register()); >> > Runtime1::StubID stub_id; >> > if (_throw_index_out_of_bounds_exception) { >> > + assert(_array != NULL, "sanity"); >> > + __ mov(rscratch2, _array->as_pointer_register()); >> > stub_id = Runtime1::throw_index_exception_id; >> > } else { >> > stub_id = Runtime1::throw_range_check_failed_id; >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> >> Sent: Donnerstag, 19. April 2018 14:26 >> >> To: Lindenmaier, Goetz >> >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >> >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32- >> port- >> >> dev at openjdk.java.net >> >> Subject: Re: RFR(M): 8201593: Print array length in >> >> ArrayIndexOutOfBoundsException. >> >> >> >> Hello Goetz, >> >> In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just >> >> need to guard the emission of rscratch2 - you don't use it in one of >> >> the cases, something like: >> >> >> >> if (!_throw_index_out_of_bounds_exception) { >> >> __ mov(rscratch2, _array->as_pointer_register()); >> >> } >> >> >> >> >> >> Once I can run the unit tests, I'm seeing failures in your unit test like: >> >> >> >> java.lang.AssertionError: expected [trying to access index -5 of an >> >> array with length 0] but found [trying to access index -5 of an array >> >> with length -1459548190] >> >> >> >> >> >> BR, >> >> Stuart >> >> >> >> >> >> On 18 April 2018 at 09:09, Lindenmaier, Goetz >> >> >> wrote: >> >> > Hi, >> >> > >> >> > I would like to print a more verbose text on ArrayIndexOutOfBounds >> >> exception >> >> > that not only mentions the index, but also the length of the array >> accessed. >> >> > See the bug for documentation of the change of the message. >> >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >> >> > >> >> > @aarch/arm people: >> >> > I edited the aarch/arm files. Could you please verify this is correct? >> >> > I can not build on these platforms. >> >> > >> >> > The code on all the other platforms is tested with all the jtreg and jck >> tests >> >> etc. >> >> > >> >> > Best regards, >> >> > Goetz. >> >> > >> >> > From goetz.lindenmaier at sap.com Tue Apr 24 14:08:02 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Apr 2018 14:08:02 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Message-ID: Hi, I implemented what we figured out in http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-April/027555.html Some examples: "Index 12 out-of-bounds for length 10." "arraycopy source index -17 out of bounds for object array[10]." "arraycopy destination index -18 out of bounds for double[5]." "arraycopy length -19 is negative." "arraycopy: last source index 13 out of bounds for double[10]." "arraycopy: last destination index 7 out of bounds for long[5]." Incremental webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03-incremental/ Full webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03/ I'll push it through our tests tonight. See further comments in line: > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 20. April 2018 09:25 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi Goetz, > > This is not a file by file review ... > > On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > > > I admit my wording is not optimal. > > src/hotspot/share/oops/typeArrayKlass.cpp > > Sorry but this is still far too verbose for my tastes. The type of the > array is not relevant. For the array copy its okay to indicate src or > dst array. But the message should be clear and succinct not prose-like. > Plus you have a lot of repetition in the ss.print statements when only > one thing is changing. We discussed this in some further mails. Implemented as proposed there. > src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > > I'm not seeing why the throw_index_out_of_bounds_exception should be > tied to whether or not you have an array reference. Certainly I hate > seeing the array ref being used as an implicit bool! I split the constructor into two, one for ArrayIndexOutOfBounds, the other for IndexOutOfBounds. ... > > I extended the test to cover the exception thrown in arraycopy better > > The test seems somewhat excessive, and I now see it is because of the > more elaborate error messages you have at SAP. But with only the index > and the array length of interest here the test can be considerably smaller. > > The creation tests for ArrayIndexOutOfBoundsException don't seem > relevant in this context either. This looks more TCK like. Yes, the constructor tests are for the code not yet contributed. I simplified the tests to only check the messages. Best regards, Goetz. > > David > ----- > > > and added the elementary type to the message text. This probably > > needs improvement in the text, too. There are (currently) these cases: > > > > bject[] oa1 = new Object[10]; > > Object[] oa2 = new Object[5]; > > System.arraycopy(oa1, -17, oa2, 0, 5); > > "while trying to copy from index -17 of an object array with length 10"); > > System.arraycopy(oa1, 2, oa2, -18, 5); > > "while trying to copy to index -18 of an object array with length 5"); > > System.arraycopy(oa1, 2, oa2, 0, -19); > > "while trying to copy a negative range -19 from an object array with length > 10 to an object array with length 5"); > > System.arraycopy(oa1, 8, oa2, 0, 5); > > "while trying to copy from index 13 of an object array with length 10"); > > System.arraycopy(oa1, 1, oa2, 0, 7); > > "while trying to copy to index 7 of an object array with length 5"); > > double[] ta1 = new double[10]; > > double[] ta2 = new double[5]; > > System.arraycopy(ta1, -17, ta2, 0, 5); > > "while trying to copy from index -17 of a doubl array with length 10"); > > System.arraycopy(ta1, 2, ta2, -18, 5); > > "while trying to copy to index -18 of a double array with length 5"); > > System.arraycopy(ta1, 2, ta2, 0, -19); > > "while trying to copy a negative range -19 from a double array with length > 10 to a double array with length 5"); > > System.arraycopy(ta1, 8, ta2, 0, 5); > > "while trying to copy from index 13 of a double array with length 10"); > > System.arraycopy(ta1, 1, ta2, 0, 7); > > "while trying to copy to index 7 of a double array with length 5"); > > > > Maybe it should say: > > Arraycopy source index -1 out-of-bounds for double array of length 10. > > Arraycopy target index 10 out-of-bounds for object array of length 10. > > Negative range -19 when copying from an object array of length 10 to an > object array of length 5. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 18. April 2018 10:55 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Adding core-libs-dev as you're changing > >> java.lang.ArrayIndexOutOfBoundsException. > >> > >> I appreciate the intent here but I find the messages excessively > >> verbose. The basic error is: > >> > >> index N is outside range [0, length-1] > >> > >> David > >> > >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >> exception > >>> that not only mentions the index, but also the length of the array > accessed. > >>> See the bug for documentation of the change of the message. > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>> > >>> @aarch/arm people: > >>> I edited the aarch/arm files. Could you please verify this is correct? > >>> I can not build on these platforms. > >>> > >>> The code on all the other platforms is tested with all the jtreg and jck > tests > >> etc. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> From martin.doerr at sap.com Tue Apr 24 16:15:40 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 24 Apr 2018 16:15:40 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> Message-ID: Hi G?tz, I've reviewed the platform code except aarch64/arm and I have some requests for comment improvements. c1_CodeStubs_ppc: - Remove comment "// pass in R0". - Use std(index, -16, R1_SP). templateInterpreterGenerator_ppc.cpp: - A comment would be good: "R4_ARG2 contains the array." interp_masm_sparc.cpp: - Comment "move aberrant index into G3_scratch" needs update after register change. templateInterpreterGenerator_sparc.cpp: - Comment "index in register G3_scratch" ... "index to G4_scratch" is no longer correct. Better would be "G3_scratch contains the array. Otos_i contains the index." c1_Runtime1_x86: - Better would be to pass num_arguments instead of bool has_argument, but it works this way, too. At least the comment describing has_argument should get fixed. templateInterpreterGenerator_x86.cpp: - I think the comment "// Pass array to create more detailed exceptions." should be in front of the rarg assignment. templateTable_x86.cpp - I think LP64_ONLY + NOT_LP64 would be better than #ifdef IA32. Thanks and best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Stuart Monteith Sent: Dienstag, 24. April 2018 14:28 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net Subject: Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. Hello Goetz, It appears that it is just C1 that exhibits the problem - there has been a delay as I've been investigating a hang in Java JDK running some of my automation. I'll try and track down the issue. Otherwise, I do like the principle of the patch. BR, Stuart On 24 April 2018 at 11:44, Lindenmaier, Goetz wrote: > Hi Stuart, > > could you track down the remaining issue? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> Sent: Donnerstag, 19. April 2018 17:09 >> To: Lindenmaier, Goetz >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32-port- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi, >> I'm trying to work through what's going on here. With C1 not >> crashing, I'll check the behaviour of the interpreter and C2. I'm >> doing explicitly with -Xint, etc. WIth -Xint I definitely get the >> error. >> >> You have the condition the wrong way round - >> _throw_index_out_of_bounds_exception is true when array is NULL. >> >> >> BR, >> Stuart >> >> >> On 19 April 2018 at 15:36, Lindenmaier, Goetz >> wrote: >> > Hi Stuart, >> > >> > thanks a lot for helping out here. >> > I added below patch to my latest webrev (replaced it in-place): >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >> > >> > The remaining problem looks like the array argument does not >> > reach the method that prints the message properly. >> > Did I get a register wrong? >> > Did I use a wrong argument register, or does the untangling >> > of registers in overwrite something? >> > Is it correct to use mov and not movw in >> templateInterpreterGenerator_aarch64.cpp? >> > Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" here is >> stupid, >> > it seems to cause unnecessary register moves. But it's similar on all >> platforms.) >> > >> > The test runs several times, assuring it's C1, C2 and Xint. >> > This should help you to narrow down the problem. >> > >> > Best regards, >> > Goetz. >> > >> > >> > >> > >> > >> > >> > >> > >> > diff -r 3fe33d48aa16 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp >> > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 >> 15:17:20 2018 +0200 >> > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 >> 16:06:23 2018 +0200 >> > @@ -73,9 +73,10 @@ >> > } else { >> > __ mov(rscratch1, _index->as_jint()); >> > } >> > - __ mov(rscratch2, _array->as_pointer_register()); >> > Runtime1::StubID stub_id; >> > if (_throw_index_out_of_bounds_exception) { >> > + assert(_array != NULL, "sanity"); >> > + __ mov(rscratch2, _array->as_pointer_register()); >> > stub_id = Runtime1::throw_index_exception_id; >> > } else { >> > stub_id = Runtime1::throw_range_check_failed_id; >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> >> Sent: Donnerstag, 19. April 2018 14:26 >> >> To: Lindenmaier, Goetz >> >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >> >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32- >> port- >> >> dev at openjdk.java.net >> >> Subject: Re: RFR(M): 8201593: Print array length in >> >> ArrayIndexOutOfBoundsException. >> >> >> >> Hello Goetz, >> >> In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just >> >> need to guard the emission of rscratch2 - you don't use it in one of >> >> the cases, something like: >> >> >> >> if (!_throw_index_out_of_bounds_exception) { >> >> __ mov(rscratch2, _array->as_pointer_register()); >> >> } >> >> >> >> >> >> Once I can run the unit tests, I'm seeing failures in your unit test like: >> >> >> >> java.lang.AssertionError: expected [trying to access index -5 of an >> >> array with length 0] but found [trying to access index -5 of an array >> >> with length -1459548190] >> >> >> >> >> >> BR, >> >> Stuart >> >> >> >> >> >> On 18 April 2018 at 09:09, Lindenmaier, Goetz >> >> >> wrote: >> >> > Hi, >> >> > >> >> > I would like to print a more verbose text on ArrayIndexOutOfBounds >> >> exception >> >> > that not only mentions the index, but also the length of the array >> accessed. >> >> > See the bug for documentation of the change of the message. >> >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >> >> > >> >> > @aarch/arm people: >> >> > I edited the aarch/arm files. Could you please verify this is correct? >> >> > I can not build on these platforms. >> >> > >> >> > The code on all the other platforms is tested with all the jtreg and jck >> tests >> >> etc. >> >> > >> >> > Best regards, >> >> > Goetz. >> >> > >> >> > From goetz.lindenmaier at sap.com Tue Apr 24 16:25:25 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Apr 2018 16:25:25 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5ADF5897.8070809@cjnash.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <5ADF5897.8070809@cjnash.com> Message-ID: <819d942132204f58992c236518e0c344@sap.com> Hi Simon, Because as stated here, http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052665.html it is used in other places like that, too. Later mails agreed on that usage to keep it consistent. Best regards, Goetz. > -----Original Message----- > From: Simon Nash [mailto:simon at cjnash.com] > Sent: Dienstag, 24. April 2018 18:17 > To: Lindenmaier, Goetz > Cc: David Holmes ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > On 24/04/2018 15:08, Lindenmaier, Goetz wrote: > > Hi, > > > > I implemented what we figured out in > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018- > April/027555.html > > > > Some examples: > > "Index 12 out-of-bounds for length 10." > > "arraycopy source index -17 out of bounds for object array[10]." > > "arraycopy destination index -18 out of bounds for double[5]." > > "arraycopy length -19 is negative." > > "arraycopy: last source index 13 out of bounds for double[10]." > > "arraycopy: last destination index 7 out of bounds for long[5]." > > > Is there a reason why the first message says "out-of-bounds" but all others > say "out of bounds"? > > Simon > > > Incremental webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03- > incremental/ > > Full webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03/ > > > > I'll push it through our tests tonight. > > > > See further comments in line: > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 20. April 2018 09:25 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi Goetz, > >> > >> This is not a file by file review ... > >> > >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >>> > >>> I admit my wording is not optimal. > >> src/hotspot/share/oops/typeArrayKlass.cpp > >> > >> Sorry but this is still far too verbose for my tastes. The type of the > >> array is not relevant. For the array copy its okay to indicate src or > >> dst array. But the message should be clear and succinct not prose-like. > >> Plus you have a lot of repetition in the ss.print statements when only > >> one thing is changing. > > We discussed this in some further mails. Implemented as proposed there. > > > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > >> > >> I'm not seeing why the throw_index_out_of_bounds_exception should > be > >> tied to whether or not you have an array reference. Certainly I hate > >> seeing the array ref being used as an implicit bool! > > I split the constructor into two, one for ArrayIndexOutOfBounds, the other > > for IndexOutOfBounds. > > > > ... > > > >>> I extended the test to cover the exception thrown in arraycopy better > >> The test seems somewhat excessive, and I now see it is because of the > >> more elaborate error messages you have at SAP. But with only the index > >> and the array length of interest here the test can be considerably smaller. > >> > >> The creation tests for ArrayIndexOutOfBoundsException don't seem > >> relevant in this context either. This looks more TCK like. > > Yes, the constructor tests are for the code not yet contributed. > > I simplified the tests to only check the messages. > > > > Best regards, > > Goetz. > > > > > > > > > > > >> David > >> ----- > >> > >>> and added the elementary type to the message text. This probably > >>> needs improvement in the text, too. There are (currently) these cases: > >>> > >>> bject[] oa1 = new Object[10]; > >>> Object[] oa2 = new Object[5]; > >>> System.arraycopy(oa1, -17, oa2, 0, 5); > >>> "while trying to copy from index -17 of an object array with length 10"); > >>> System.arraycopy(oa1, 2, oa2, -18, 5); > >>> "while trying to copy to index -18 of an object array with length 5"); > >>> System.arraycopy(oa1, 2, oa2, 0, -19); > >>> "while trying to copy a negative range -19 from an object array with > length > >> 10 to an object array with length 5"); > >>> System.arraycopy(oa1, 8, oa2, 0, 5); > >>> "while trying to copy from index 13 of an object array with length 10"); > >>> System.arraycopy(oa1, 1, oa2, 0, 7); > >>> "while trying to copy to index 7 of an object array with length 5"); > >>> double[] ta1 = new double[10]; > >>> double[] ta2 = new double[5]; > >>> System.arraycopy(ta1, -17, ta2, 0, 5); > >>> "while trying to copy from index -17 of a doubl array with length 10"); > >>> System.arraycopy(ta1, 2, ta2, -18, 5); > >>> "while trying to copy to index -18 of a double array with length 5"); > >>> System.arraycopy(ta1, 2, ta2, 0, -19); > >>> "while trying to copy a negative range -19 from a double array with > length > >> 10 to a double array with length 5"); > >>> System.arraycopy(ta1, 8, ta2, 0, 5); > >>> "while trying to copy from index 13 of a double array with length 10"); > >>> System.arraycopy(ta1, 1, ta2, 0, 7); > >>> "while trying to copy to index 7 of a double array with length 5"); > >>> > >>> Maybe it should say: > >>> Arraycopy source index -1 out-of-bounds for double array of length 10. > >>> Arraycopy target index 10 out-of-bounds for object array of length 10. > >>> Negative range -19 when copying from an object array of length 10 to an > >> object array of length 5. > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 18. April 2018 10:55 > >>>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > >> aarch64- > >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; > core- > >> libs- > >>>> dev Libs > >>>> Subject: Re: RFR(M): 8201593: Print array length in > >>>> ArrayIndexOutOfBoundsException. > >>>> > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>> exception > >>>>> that not only mentions the index, but also the length of the array > >> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg and jck > >> tests > >>>> etc. > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From gnu.andrew at redhat.com Tue Apr 24 18:59:12 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 24 Apr 2018 19:59:12 +0100 Subject: [aarch64-port-dev ] [RFR] 8u171 Update In-Reply-To: <898a7b4a-c6c3-6713-3712-61f927c1815f@redhat.com> References: <898a7b4a-c6c3-6713-3712-61f927c1815f@redhat.com> Message-ID: On 24 April 2018 at 08:09, Aleksey Shipilev wrote: > On 04/24/2018 05:35 AM, Andrew Hughes wrote: >> Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u171-b10. >> http://cr.openjdk.java.net/~andrew/aarch64-8/u171/ > > corba looks ok. > hotspot looks ok. > jaxp looks ok. > jdk looks ok. > jaxws looks ok. > langtools looks ok. > nashorn looks ok. > > All good. > Thanks. I'll push. >> The Shenandoah merge is: >> http://cr.openjdk.java.net/~andrew/aarch64-8/u171/hotspot/shenandoah.merge.b10 > > Missing bits in cpp/fixup_cloned_reference: > > *) "if (UseG1GC)" should be "if (UseG1GC || UseShenandoahGC)" -- Shenandoah/8u piggybacks on G1 on > this path > > *) oopDesc::equals is missing, Shenandoah needs it for correctness: > > "(java_lang_ref_Reference::queue(clone) == java_lang_ref_ReferenceQueue::ENQUEUED_queue())" > > should be: > > "(oopDesc::equals(java_lang_ref_Reference::queue(clone), > java_lang_ref_ReferenceQueue::ENQUEUED_queue())))" > > I can fix them after the merge. > Right, that sounds more like Shenandoah support for "8192025: Less referential references" than a merge issue. Have you made the same changes for Shenandoah in 10 & 11? > Thanks, > -Aleksey > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Apr 24 18:59:42 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 18:59:42 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u: Added tag aarch64-jdk8u171-b10 for changeset f8e58f4c29ae Message-ID: <201804241859.w3OIxg0Q001812@aojmv0008.oracle.com> Changeset: 58bf8f7f184d Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/rev/58bf8f7f184d Added tag aarch64-jdk8u171-b10 for changeset f8e58f4c29ae ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 18:59:49 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 18:59:49 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/corba: 3 new changesets Message-ID: <201804241859.w3OIxnqE001874@aojmv0008.oracle.com> Changeset: 39ac51f8ed50 Author: rpatil Date: 2018-02-07 00:10 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/39ac51f8ed50 8192757: Improve stub classes implementation Reviewed-by: rriggs, dfuchs, erikj ! make/BuildCorba.gmk ! src/share/classes/com/sun/corba/se/impl/ior/StubIORImpl.java ! src/share/classes/sun/corba/SharedSecrets.java + src/share/classes/sun/misc/JavaOISAccess.java + src/share/classes/sun/misc/ObjectInputFilter.java Changeset: 0aa1941541ff Author: rpatil Date: 2018-02-27 19:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/0aa1941541ff 8198494: 8u171 and 8u172 - Build failure on non-SE Linux Platforms Reviewed-by: dfuchs, rriggs, coffeys, aefimov ! src/share/classes/com/sun/corba/se/impl/ior/StubIORImpl.java ! src/share/classes/sun/corba/SharedSecrets.java Changeset: e8d4f321311a Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/e8d4f321311a Added tag aarch64-jdk8u171-b10 for changeset 0aa1941541ff ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 18:59:58 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 18:59:58 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jaxp: 2 new changesets Message-ID: <201804241859.w3OIxwPP001950@aojmv0008.oracle.com> Changeset: 9b2f66185694 Author: aefimov Date: 2018-01-29 12:56 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/9b2f66185694 8189993: Improve document portability Reviewed-by: joehw ! src/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java Changeset: 0ecfb39b8cfd Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/0ecfb39b8cfd Added tag aarch64-jdk8u171-b10 for changeset 9b2f66185694 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:00:05 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:00:05 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jaxws: 2 new changesets Message-ID: <201804241900.w3OJ05eR002025@aojmv0008.oracle.com> Changeset: 5cd737156e9e Author: aefimov Date: 2017-12-02 14:27 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxws/rev/5cd737156e9e 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class Reviewed-by: lancea ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SaajStaxWriter.java Changeset: 7ffd685f5516 Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxws/rev/7ffd685f5516 Added tag aarch64-jdk8u171-b10 for changeset 5cd737156e9e ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:00:13 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:00:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/langtools: 2 new changesets Message-ID: <201804241900.w3OJ0Du3002251@aojmv0008.oracle.com> Changeset: 3bee84de4b91 Author: igerasim Date: 2018-02-06 09:06 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/langtools/rev/3bee84de4b91 8189997: Enhance keystore mechanisms 8194259: keytool error: java.io.IOException: Invalid secret key format Reviewed-by: mullan, valeriep, rriggs, ahgross ! test/tools/javap/T6587786.java Changeset: 6c58348c39c2 Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/langtools/rev/6c58348c39c2 Added tag aarch64-jdk8u171-b10 for changeset 3bee84de4b91 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:00:22 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:00:22 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8 new changesets Message-ID: <201804241900.w3OJ0N2N002536@aojmv0008.oracle.com> Changeset: 453297ed33d5 Author: robm Date: 2017-10-27 20:39 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/453297ed33d5 8180881: Better packaging of deserialization Reviewed-by: chegar, acorn ! src/share/vm/prims/jvm.cpp Changeset: cf14489f6650 Author: hseigel Date: 2017-11-08 09:17 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/cf14489f6650 8189123: More consistent classloading Reviewed-by: acorn, ahgross, rhalade Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/prims/jvm.cpp Changeset: b97e5721a5d8 Author: hseigel Date: 2017-12-05 13:25 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/b97e5721a5d8 8190478: Improved interface method selection Reviewed-by: acorn, ahgross, jwilhelm, rhalade Contributed-by: harold.seigel at oracle.com ! src/share/vm/oops/cpCache.cpp Changeset: 6c61a1a1cb15 Author: thartmann Date: 2017-11-28 12:14 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/6c61a1a1cb15 8190877: Better handling of abstract classes Reviewed-by: kvn, vlivanov, rhalade, ahgross, jwilhelm Contributed-by: tobias.hartmann at oracle.com ! src/share/vm/code/dependencies.cpp Changeset: 5873fa171ca5 Author: kbarrett Date: 2018-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/5873fa171ca5 8192025: Less referential references Reviewed-by: coleenp, eosterlund, mchung, ahgross, rhalade ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvm.cpp Changeset: de07fadb740e Author: bgopularam Date: 2018-02-22 21:28 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/de07fadb740e 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available Reviewed-by: coleenp, sla ! test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Changeset: 5ba4bd640986 Author: dbuck Date: 2017-12-18 18:18 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/5ba4bd640986 8189851: [TESTBUG] runtime/RedefineTests/RedefineInterfaceCall.java fails Summary: modified jtreg tags and package import to work with JDK 8 Reviewed-by: vlivanov, dholmes ! test/runtime/RedefineTests/RedefineInterfaceCall.java Changeset: bf7bd0b13ecb Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/bf7bd0b13ecb Added tag aarch64-jdk8u171-b10 for changeset 5ba4bd640986 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:00:33 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:00:33 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jdk: 36 new changesets Message-ID: <201804241900.w3OJ0YUa002711@aojmv0008.oracle.com> Changeset: f339a33b0825 Author: rpatil Date: 2017-10-11 15:47 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/f339a33b0825 8169080: Improve documentation examples for crypto applications Reviewed-by: wetmore Contributed-by: prasadarao.koppula at oracle.com ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SealedObject.java Changeset: 7e39f2b3070b Author: robm Date: 2017-10-27 20:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/7e39f2b3070b 8180881: Better packaging of deserialization Reviewed-by: chegar, acorn ! make/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/sun/misc/VM.c Changeset: e00f4050c338 Author: apetcher Date: 2018-01-16 13:27 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/e00f4050c338 8182362: Update CipherOutputStream Usage Summary: Clarify spec of CipherOutputStream in Javadoc comments Reviewed-by: ascarpino ! src/share/classes/javax/crypto/CipherOutputStream.java Changeset: fce0c5d40650 Author: prr Date: 2017-12-07 09:11 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/fce0c5d40650 8183032: Upgrade to LittleCMS 2.9 Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsalpha.c ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c ! src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: dcf8fbd779fb Author: coffeys Date: 2018-01-15 13:17 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/dcf8fbd779fb 8189969: Manifest better manifest entries Reviewed-by: weijun, igerasim ! src/share/classes/sun/security/util/ManifestDigester.java Changeset: 03452687316a Author: igerasim Date: 2018-01-05 20:11 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/03452687316a 8189977: Improve permission portability Reviewed-by: rriggs ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/Vector.java Changeset: 3807cc8c6284 Author: igerasim Date: 2018-02-05 04:31 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/3807cc8c6284 8189981: Improve queuing portability Reviewed-by: skoivu, rhalade, chegar, igerasim ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java Changeset: e236e1095943 Author: mchinnathamb Date: 2018-02-16 01:37 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/e236e1095943 8189985: Improve tabular data portability Reviewed-by: dfuchs, robm ! src/share/classes/javax/management/openmbean/TabularDataSupport.java Changeset: 1f67a5f331ef Author: serb Date: 2017-11-15 07:07 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/1f67a5f331ef 8189989: Improve container portability Reviewed-by: prr, azvegint, rhalade, skoivu ! src/share/classes/java/awt/Container.java Changeset: cb893fee50ad Author: igerasim Date: 2018-02-06 09:04 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/cb893fee50ad 8189997: Enhance keystore mechanisms 8194259: keytool error: java.io.IOException: Invalid secret key format Reviewed-by: mullan, valeriep, rriggs, ahgross ! src/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java - src/share/classes/com/sun/crypto/provider/ai.java ! src/share/classes/javax/crypto/SealedObject.java + src/share/classes/sun/misc/JavaxCryptoSealedObjectAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 189b2c3562cf Author: serb Date: 2018-01-03 19:24 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/189b2c3562cf 8191696: Better mouse positioning Reviewed-by: skoivu, rhalade, prr, aghaisas ! src/solaris/classes/sun/awt/X11/XMouseInfoPeer.java ! src/windows/native/sun/windows/MouseInfo.cpp Changeset: cde60c03a9de Author: serb Date: 2017-12-10 19:01 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/cde60c03a9de 8192030: Better MTSchema support Reviewed-by: skoivu, rhalade, prr, aghaisas ! src/windows/classes/sun/awt/windows/ThemeReader.java ! src/windows/native/sun/windows/ThemeReader.cpp Changeset: 5594f8258a2f Author: rpatil Date: 2018-02-07 00:09 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/5594f8258a2f 8192757: Improve stub classes implementation Reviewed-by: rriggs, dfuchs, erikj ! src/share/classes/java/io/ObjectInputStream.java Changeset: 8c1764639919 Author: igerasim Date: 2018-01-30 11:43 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/8c1764639919 8193409: Improve AES supporting classes Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Changeset: 801aaa8b9880 Author: igerasim Date: 2018-01-02 21:04 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/801aaa8b9880 8193414: Improvements in MethodType lookups Reviewed-by: ahgross, jrose ! src/share/classes/java/lang/invoke/MethodType.java Changeset: cd9ff3a9443d Author: robm Date: 2018-02-15 19:03 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/cd9ff3a9443d 8193833: Better RMI connection support Reviewed-by: smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java Changeset: 3bf943d2b768 Author: snikandrova Date: 2016-07-18 14:39 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/3bf943d2b768 8054213: Class name repeated in output of Type.toString() Reviewed-by: darcy ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java + test/java/lang/reflect/Generics/TestGenericReturnTypeToString.java Changeset: a4452bc28995 Author: igerasim Date: 2017-11-29 21:01 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/a4452bc28995 8150530: Improve javax.crypto.BadPaddingException messages Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/rsa/RSAPadding.java ! src/share/classes/sun/security/ssl/CipherBox.java Changeset: 30ae1f03041f Author: rpatil Date: 2017-12-20 06:12 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/30ae1f03041f 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit Summary: This patch adds a new JDK implementation specific system property "jdk.internal.FileHandlerLogging.maxLocks" to control java.util.logging.FileHandler's MAX_LOCKS limit. Reviewed-by: coffeys, dfuchs ! src/share/classes/java/util/logging/FileHandler.java + test/java/util/logging/FileHandlerMaxLocksTest.java Changeset: 7326d664d3d8 Author: igerasim Date: 2018-01-23 08:17 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/7326d664d3d8 8175075: Add 3DES to the default disabled algorithm security property Reviewed-by: xuelei, mullan, rhalade ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java Changeset: af79c072c92a Author: aivanov Date: 2017-12-06 13:04 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/af79c072c92a 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location Reviewed-by: prr, serb, ssadetsky ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/native/sun/windows/awt_Component.cpp + test/javax/swing/JFrame/AlwaysOnTop/AlwaysOnTopImeTest.java Changeset: f812a4eeb16d Author: robm Date: 2018-01-12 22:16 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/f812a4eeb16d 8186032: Disable XML Signatures signed with EC keys less than 224 bits Reviewed-by: mullan ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2a177fd47925 Author: aefimov Date: 2017-12-02 14:28 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/2a177fd47925 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class Reviewed-by: lancea ! test/javax/xml/ws/8159058/SaajEmptyNamespaceTest.java Changeset: 53f411d24c2e Author: igerasim Date: 2017-12-13 11:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/53f411d24c2e 8187496: Possible memory leak in java.apple.security.KeychainStore.addItemToKeychain Reviewed-by: weijun, mullan, ahgross ! src/macosx/native/apple/security/KeystoreImpl.m Changeset: 0cbb9f77afbb Author: coffeys Date: 2017-11-27 16:53 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/0cbb9f77afbb 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151 Reviewed-by: sherman, phh ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/zlib/deflate.c ! src/share/native/java/util/zip/zlib/patches/ChangeLog_java ! test/java/util/zip/InflateIn_DeflateOut.java Changeset: 2bd1a424c1a5 Author: mullan Date: 2017-12-08 09:37 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/2bd1a424c1a5 8191358: Restore TSA certificate expiration check Reviewed-by: coffeys, rhalade ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java Changeset: e58e7f418792 Author: robm Date: 2018-02-20 14:00 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/e58e7f418792 8191909: Nightly failures in nashorn suite Reviewed-by: chegar ! src/share/classes/sun/misc/Launcher.java Changeset: c260a8bb7e48 Author: igerasim Date: 2017-12-12 23:34 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/c260a8bb7e48 8192789: Avoid using AtomicReference in sun.security.provider.PolicyFile Reviewed-by: mullan, ahgross ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: 20fdfd694497 Author: rpatil Date: 2018-02-05 00:15 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/20fdfd694497 8195837: (tz) Upgrade time-zone data to tzdata2018c Reviewed-by: coffeys, naoto ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/southamerica ! make/data/tzdata/zone.tab ! src/share/classes/java/time/format/ZoneName.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/time/test/java/time/format/ZoneName.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: f30e034ab55e Author: andrew Date: 2018-02-23 05:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/f30e034ab55e 8196952: Bad primeCertainty value setting in DSAParameterGenerator Summary: OpenJDK 8 applied 8072452 after 8181048, reverting parts of the latter Reviewed-by: coffeys ! src/share/classes/sun/security/provider/DSAParameterGenerator.java Changeset: c2db10d79c27 Author: coffeys Date: 2018-02-13 09:25 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/c2db10d79c27 8197030: Perf regression on all platforms with 8u171-b03 - early lambda use Reviewed-by: weijun ! src/share/classes/sun/security/util/ManifestDigester.java Changeset: 37f24464b954 Author: rpatil Date: 2018-02-27 19:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/37f24464b954 8198494: 8u171 and 8u172 - Build failure on non-SE Linux Platforms Reviewed-by: dfuchs, rriggs, coffeys, aefimov ! src/share/classes/java/io/ObjectInputStream.java Changeset: 6f002f9bcd4e Author: shshahma Date: 2018-03-02 01:03 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/6f002f9bcd4e 8198662: Incompatible internal API change in JDK8u161: signature of method exportObject() Reviewed-by: dfuchs, robm, jwilhelm, rriggs ! src/share/classes/com/sun/jmx/remote/internal/RMIExporter.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java + src/share/classes/sun/misc/JavaObjectInputStreamAccess.java + src/share/classes/sun/misc/ObjectStreamClassValidator.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/lib/management/management.properties ! test/javax/management/remote/mandatory/connectorServer/RMIExporterTest.java Changeset: c061bc876fe5 Author: robm Date: 2018-03-04 16:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/c061bc876fe5 8198963: Fix new rmi property name Reviewed-by: smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java Changeset: bb1b68c7809e Author: shshahma Date: 2018-03-05 10:23 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/bb1b68c7809e 8199001: [TESTBUG] RMIConnectionFilterTest.java test fails in compilation Reviewed-by: dfuchs, robm - test/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java - test/javax/management/remote/mandatory/connection/NewRMIClientFilterTest.java - test/javax/management/remote/mandatory/connection/mgmt1.properties - test/javax/management/remote/mandatory/connection/mgmt2.properties Changeset: 9239d945aa4f Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/9239d945aa4f Added tag aarch64-jdk8u171-b10 for changeset bb1b68c7809e ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:00:42 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:00:42 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/nashorn: Added tag aarch64-jdk8u171-b10 for changeset 31efd519fdb3 Message-ID: <201804241900.w3OJ0gVE002780@aojmv0008.oracle.com> Changeset: eb038e0fd088 Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/nashorn/rev/eb038e0fd088 Added tag aarch64-jdk8u171-b10 for changeset 31efd519fdb3 ! .hgtags From shade at redhat.com Tue Apr 24 19:01:50 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Apr 2018 21:01:50 +0200 Subject: [aarch64-port-dev ] [RFR] 8u171 Update In-Reply-To: References: <898a7b4a-c6c3-6713-3712-61f927c1815f@redhat.com> Message-ID: On 04/24/2018 08:59 PM, Andrew Hughes wrote: >>> The Shenandoah merge is: >>> http://cr.openjdk.java.net/~andrew/aarch64-8/u171/hotspot/shenandoah.merge.b10 >> >> Missing bits in cpp/fixup_cloned_reference: >> >> *) "if (UseG1GC)" should be "if (UseG1GC || UseShenandoahGC)" -- Shenandoah/8u piggybacks on G1 on >> this path >> >> *) oopDesc::equals is missing, Shenandoah needs it for correctness: >> >> "(java_lang_ref_Reference::queue(clone) == java_lang_ref_ReferenceQueue::ENQUEUED_queue())" >> >> should be: >> >> "(oopDesc::equals(java_lang_ref_Reference::queue(clone), >> java_lang_ref_ReferenceQueue::ENQUEUED_queue())))" >> >> I can fix them after the merge. >> > > Right, that sounds more like Shenandoah support for "8192025: Less > referential references" than a merge issue. > > Have you made the same changes for Shenandoah in 10 & 11? Yes, we did pick up jdk10 merge with the same change, and it was fixed as above. jdk11 has the whole thing a bit differently, IIRC. Thanks, -Aleksey From gnu.andrew at redhat.com Tue Apr 24 19:10:09 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:10:09 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <201804241910.w3OJA946007750@aojmv0008.oracle.com> Changeset: 58bf8f7f184d Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/58bf8f7f184d Added tag aarch64-jdk8u171-b10 for changeset f8e58f4c29ae ! .hgtags Changeset: 3cea13523e78 Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/3cea13523e78 Merge aarch64-jdk8u171-b10 ! .hgtags Changeset: 9a6d58cb5433 Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/9a6d58cb5433 Added tag aarch64-shenandoah-jdk8u171-b10 for changeset 3cea13523e78 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:10:17 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:10:17 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 5 new changesets Message-ID: <201804241910.w3OJAIPW007934@aojmv0008.oracle.com> Changeset: 39ac51f8ed50 Author: rpatil Date: 2018-02-07 00:10 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/39ac51f8ed50 8192757: Improve stub classes implementation Reviewed-by: rriggs, dfuchs, erikj ! make/BuildCorba.gmk ! src/share/classes/com/sun/corba/se/impl/ior/StubIORImpl.java ! src/share/classes/sun/corba/SharedSecrets.java + src/share/classes/sun/misc/JavaOISAccess.java + src/share/classes/sun/misc/ObjectInputFilter.java Changeset: 0aa1941541ff Author: rpatil Date: 2018-02-27 19:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/0aa1941541ff 8198494: 8u171 and 8u172 - Build failure on non-SE Linux Platforms Reviewed-by: dfuchs, rriggs, coffeys, aefimov ! src/share/classes/com/sun/corba/se/impl/ior/StubIORImpl.java ! src/share/classes/sun/corba/SharedSecrets.java Changeset: e8d4f321311a Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/e8d4f321311a Added tag aarch64-jdk8u171-b10 for changeset 0aa1941541ff ! .hgtags Changeset: 4dc1e92e5ba2 Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/4dc1e92e5ba2 Merge aarch64-jdk8u171-b10 ! .hgtags Changeset: 4b0030f5be4c Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/4b0030f5be4c Added tag aarch64-shenandoah-jdk8u171-b10 for changeset 4dc1e92e5ba2 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:10:26 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:10:26 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 4 new changesets Message-ID: <201804241910.w3OJAQa5008082@aojmv0008.oracle.com> Changeset: 9b2f66185694 Author: aefimov Date: 2018-01-29 12:56 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/9b2f66185694 8189993: Improve document portability Reviewed-by: joehw ! src/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java Changeset: 0ecfb39b8cfd Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/0ecfb39b8cfd Added tag aarch64-jdk8u171-b10 for changeset 9b2f66185694 ! .hgtags Changeset: a96e6e5e3166 Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/a96e6e5e3166 Merge aarch64-jdk8u171-b10 ! .hgtags Changeset: 978bc5727c43 Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/978bc5727c43 Added tag aarch64-shenandoah-jdk8u171-b10 for changeset a96e6e5e3166 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:10:34 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:10:34 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 4 new changesets Message-ID: <201804241910.w3OJAZGF008222@aojmv0008.oracle.com> Changeset: 5cd737156e9e Author: aefimov Date: 2017-12-02 14:27 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/5cd737156e9e 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class Reviewed-by: lancea ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SaajStaxWriter.java Changeset: 7ffd685f5516 Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/7ffd685f5516 Added tag aarch64-jdk8u171-b10 for changeset 5cd737156e9e ! .hgtags Changeset: 3686a81313f5 Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/3686a81313f5 Merge aarch64-jdk8u171-b10 ! .hgtags Changeset: ff2758da1e05 Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/ff2758da1e05 Added tag aarch64-shenandoah-jdk8u171-b10 for changeset 3686a81313f5 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:10:43 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:10:43 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 4 new changesets Message-ID: <201804241910.w3OJAhAZ008292@aojmv0008.oracle.com> Changeset: 3bee84de4b91 Author: igerasim Date: 2018-02-06 09:06 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/3bee84de4b91 8189997: Enhance keystore mechanisms 8194259: keytool error: java.io.IOException: Invalid secret key format Reviewed-by: mullan, valeriep, rriggs, ahgross ! test/tools/javap/T6587786.java Changeset: 6c58348c39c2 Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/6c58348c39c2 Added tag aarch64-jdk8u171-b10 for changeset 3bee84de4b91 ! .hgtags Changeset: e85f3e7aa6d2 Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/e85f3e7aa6d2 Merge aarch64-jdk8u171-b10 ! .hgtags Changeset: 3ef8b2fa808b Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/3ef8b2fa808b Added tag aarch64-shenandoah-jdk8u171-b10 for changeset e85f3e7aa6d2 ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:10:51 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:10:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 10 new changesets Message-ID: <201804241910.w3OJAqqN008371@aojmv0008.oracle.com> Changeset: 453297ed33d5 Author: robm Date: 2017-10-27 20:39 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/453297ed33d5 8180881: Better packaging of deserialization Reviewed-by: chegar, acorn ! src/share/vm/prims/jvm.cpp Changeset: cf14489f6650 Author: hseigel Date: 2017-11-08 09:17 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cf14489f6650 8189123: More consistent classloading Reviewed-by: acorn, ahgross, rhalade Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/prims/jvm.cpp Changeset: b97e5721a5d8 Author: hseigel Date: 2017-12-05 13:25 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b97e5721a5d8 8190478: Improved interface method selection Reviewed-by: acorn, ahgross, jwilhelm, rhalade Contributed-by: harold.seigel at oracle.com ! src/share/vm/oops/cpCache.cpp Changeset: 6c61a1a1cb15 Author: thartmann Date: 2017-11-28 12:14 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6c61a1a1cb15 8190877: Better handling of abstract classes Reviewed-by: kvn, vlivanov, rhalade, ahgross, jwilhelm Contributed-by: tobias.hartmann at oracle.com ! src/share/vm/code/dependencies.cpp Changeset: 5873fa171ca5 Author: kbarrett Date: 2018-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5873fa171ca5 8192025: Less referential references Reviewed-by: coleenp, eosterlund, mchung, ahgross, rhalade ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvm.cpp Changeset: de07fadb740e Author: bgopularam Date: 2018-02-22 21:28 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/de07fadb740e 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available Reviewed-by: coleenp, sla ! test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Changeset: 5ba4bd640986 Author: dbuck Date: 2017-12-18 18:18 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5ba4bd640986 8189851: [TESTBUG] runtime/RedefineTests/RedefineInterfaceCall.java fails Summary: modified jtreg tags and package import to work with JDK 8 Reviewed-by: vlivanov, dholmes ! test/runtime/RedefineTests/RedefineInterfaceCall.java Changeset: bf7bd0b13ecb Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bf7bd0b13ecb Added tag aarch64-jdk8u171-b10 for changeset 5ba4bd640986 ! .hgtags Changeset: 89312ba8c5de Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/89312ba8c5de Merge aarch64-jdk8u171-b10 ! .hgtags ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvm.cpp Changeset: db8079be23d7 Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/db8079be23d7 Added tag aarch64-shenandoah-jdk8u171-b10 for changeset 89312ba8c5de ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:11:04 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:11:04 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 38 new changesets Message-ID: <201804241911.w3OJB5oW008500@aojmv0008.oracle.com> Changeset: f339a33b0825 Author: rpatil Date: 2017-10-11 15:47 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f339a33b0825 8169080: Improve documentation examples for crypto applications Reviewed-by: wetmore Contributed-by: prasadarao.koppula at oracle.com ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SealedObject.java Changeset: 7e39f2b3070b Author: robm Date: 2017-10-27 20:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7e39f2b3070b 8180881: Better packaging of deserialization Reviewed-by: chegar, acorn ! make/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/sun/misc/VM.c Changeset: e00f4050c338 Author: apetcher Date: 2018-01-16 13:27 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e00f4050c338 8182362: Update CipherOutputStream Usage Summary: Clarify spec of CipherOutputStream in Javadoc comments Reviewed-by: ascarpino ! src/share/classes/javax/crypto/CipherOutputStream.java Changeset: fce0c5d40650 Author: prr Date: 2017-12-07 09:11 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/fce0c5d40650 8183032: Upgrade to LittleCMS 2.9 Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsalpha.c ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c ! src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: dcf8fbd779fb Author: coffeys Date: 2018-01-15 13:17 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/dcf8fbd779fb 8189969: Manifest better manifest entries Reviewed-by: weijun, igerasim ! src/share/classes/sun/security/util/ManifestDigester.java Changeset: 03452687316a Author: igerasim Date: 2018-01-05 20:11 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/03452687316a 8189977: Improve permission portability Reviewed-by: rriggs ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/Vector.java Changeset: 3807cc8c6284 Author: igerasim Date: 2018-02-05 04:31 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3807cc8c6284 8189981: Improve queuing portability Reviewed-by: skoivu, rhalade, chegar, igerasim ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java Changeset: e236e1095943 Author: mchinnathamb Date: 2018-02-16 01:37 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e236e1095943 8189985: Improve tabular data portability Reviewed-by: dfuchs, robm ! src/share/classes/javax/management/openmbean/TabularDataSupport.java Changeset: 1f67a5f331ef Author: serb Date: 2017-11-15 07:07 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1f67a5f331ef 8189989: Improve container portability Reviewed-by: prr, azvegint, rhalade, skoivu ! src/share/classes/java/awt/Container.java Changeset: cb893fee50ad Author: igerasim Date: 2018-02-06 09:04 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/cb893fee50ad 8189997: Enhance keystore mechanisms 8194259: keytool error: java.io.IOException: Invalid secret key format Reviewed-by: mullan, valeriep, rriggs, ahgross ! src/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java - src/share/classes/com/sun/crypto/provider/ai.java ! src/share/classes/javax/crypto/SealedObject.java + src/share/classes/sun/misc/JavaxCryptoSealedObjectAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 189b2c3562cf Author: serb Date: 2018-01-03 19:24 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/189b2c3562cf 8191696: Better mouse positioning Reviewed-by: skoivu, rhalade, prr, aghaisas ! src/solaris/classes/sun/awt/X11/XMouseInfoPeer.java ! src/windows/native/sun/windows/MouseInfo.cpp Changeset: cde60c03a9de Author: serb Date: 2017-12-10 19:01 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/cde60c03a9de 8192030: Better MTSchema support Reviewed-by: skoivu, rhalade, prr, aghaisas ! src/windows/classes/sun/awt/windows/ThemeReader.java ! src/windows/native/sun/windows/ThemeReader.cpp Changeset: 5594f8258a2f Author: rpatil Date: 2018-02-07 00:09 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/5594f8258a2f 8192757: Improve stub classes implementation Reviewed-by: rriggs, dfuchs, erikj ! src/share/classes/java/io/ObjectInputStream.java Changeset: 8c1764639919 Author: igerasim Date: 2018-01-30 11:43 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8c1764639919 8193409: Improve AES supporting classes Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Changeset: 801aaa8b9880 Author: igerasim Date: 2018-01-02 21:04 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/801aaa8b9880 8193414: Improvements in MethodType lookups Reviewed-by: ahgross, jrose ! src/share/classes/java/lang/invoke/MethodType.java Changeset: cd9ff3a9443d Author: robm Date: 2018-02-15 19:03 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/cd9ff3a9443d 8193833: Better RMI connection support Reviewed-by: smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java Changeset: 3bf943d2b768 Author: snikandrova Date: 2016-07-18 14:39 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3bf943d2b768 8054213: Class name repeated in output of Type.toString() Reviewed-by: darcy ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java + test/java/lang/reflect/Generics/TestGenericReturnTypeToString.java Changeset: a4452bc28995 Author: igerasim Date: 2017-11-29 21:01 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a4452bc28995 8150530: Improve javax.crypto.BadPaddingException messages Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/rsa/RSAPadding.java ! src/share/classes/sun/security/ssl/CipherBox.java Changeset: 30ae1f03041f Author: rpatil Date: 2017-12-20 06:12 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/30ae1f03041f 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit Summary: This patch adds a new JDK implementation specific system property "jdk.internal.FileHandlerLogging.maxLocks" to control java.util.logging.FileHandler's MAX_LOCKS limit. Reviewed-by: coffeys, dfuchs ! src/share/classes/java/util/logging/FileHandler.java + test/java/util/logging/FileHandlerMaxLocksTest.java Changeset: 7326d664d3d8 Author: igerasim Date: 2018-01-23 08:17 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7326d664d3d8 8175075: Add 3DES to the default disabled algorithm security property Reviewed-by: xuelei, mullan, rhalade ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java Changeset: af79c072c92a Author: aivanov Date: 2017-12-06 13:04 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/af79c072c92a 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location Reviewed-by: prr, serb, ssadetsky ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/native/sun/windows/awt_Component.cpp + test/javax/swing/JFrame/AlwaysOnTop/AlwaysOnTopImeTest.java Changeset: f812a4eeb16d Author: robm Date: 2018-01-12 22:16 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f812a4eeb16d 8186032: Disable XML Signatures signed with EC keys less than 224 bits Reviewed-by: mullan ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2a177fd47925 Author: aefimov Date: 2017-12-02 14:28 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2a177fd47925 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class Reviewed-by: lancea ! test/javax/xml/ws/8159058/SaajEmptyNamespaceTest.java Changeset: 53f411d24c2e Author: igerasim Date: 2017-12-13 11:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/53f411d24c2e 8187496: Possible memory leak in java.apple.security.KeychainStore.addItemToKeychain Reviewed-by: weijun, mullan, ahgross ! src/macosx/native/apple/security/KeystoreImpl.m Changeset: 0cbb9f77afbb Author: coffeys Date: 2017-11-27 16:53 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0cbb9f77afbb 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151 Reviewed-by: sherman, phh ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/zlib/deflate.c ! src/share/native/java/util/zip/zlib/patches/ChangeLog_java ! test/java/util/zip/InflateIn_DeflateOut.java Changeset: 2bd1a424c1a5 Author: mullan Date: 2017-12-08 09:37 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2bd1a424c1a5 8191358: Restore TSA certificate expiration check Reviewed-by: coffeys, rhalade ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java Changeset: e58e7f418792 Author: robm Date: 2018-02-20 14:00 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e58e7f418792 8191909: Nightly failures in nashorn suite Reviewed-by: chegar ! src/share/classes/sun/misc/Launcher.java Changeset: c260a8bb7e48 Author: igerasim Date: 2017-12-12 23:34 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c260a8bb7e48 8192789: Avoid using AtomicReference in sun.security.provider.PolicyFile Reviewed-by: mullan, ahgross ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: 20fdfd694497 Author: rpatil Date: 2018-02-05 00:15 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/20fdfd694497 8195837: (tz) Upgrade time-zone data to tzdata2018c Reviewed-by: coffeys, naoto ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/southamerica ! make/data/tzdata/zone.tab ! src/share/classes/java/time/format/ZoneName.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/time/test/java/time/format/ZoneName.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: f30e034ab55e Author: andrew Date: 2018-02-23 05:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f30e034ab55e 8196952: Bad primeCertainty value setting in DSAParameterGenerator Summary: OpenJDK 8 applied 8072452 after 8181048, reverting parts of the latter Reviewed-by: coffeys ! src/share/classes/sun/security/provider/DSAParameterGenerator.java Changeset: c2db10d79c27 Author: coffeys Date: 2018-02-13 09:25 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c2db10d79c27 8197030: Perf regression on all platforms with 8u171-b03 - early lambda use Reviewed-by: weijun ! src/share/classes/sun/security/util/ManifestDigester.java Changeset: 37f24464b954 Author: rpatil Date: 2018-02-27 19:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/37f24464b954 8198494: 8u171 and 8u172 - Build failure on non-SE Linux Platforms Reviewed-by: dfuchs, rriggs, coffeys, aefimov ! src/share/classes/java/io/ObjectInputStream.java Changeset: 6f002f9bcd4e Author: shshahma Date: 2018-03-02 01:03 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6f002f9bcd4e 8198662: Incompatible internal API change in JDK8u161: signature of method exportObject() Reviewed-by: dfuchs, robm, jwilhelm, rriggs ! src/share/classes/com/sun/jmx/remote/internal/RMIExporter.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java + src/share/classes/sun/misc/JavaObjectInputStreamAccess.java + src/share/classes/sun/misc/ObjectStreamClassValidator.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/lib/management/management.properties ! test/javax/management/remote/mandatory/connectorServer/RMIExporterTest.java Changeset: c061bc876fe5 Author: robm Date: 2018-03-04 16:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c061bc876fe5 8198963: Fix new rmi property name Reviewed-by: smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java Changeset: bb1b68c7809e Author: shshahma Date: 2018-03-05 10:23 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/bb1b68c7809e 8199001: [TESTBUG] RMIConnectionFilterTest.java test fails in compilation Reviewed-by: dfuchs, robm - test/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java - test/javax/management/remote/mandatory/connection/NewRMIClientFilterTest.java - test/javax/management/remote/mandatory/connection/mgmt1.properties - test/javax/management/remote/mandatory/connection/mgmt2.properties Changeset: 9239d945aa4f Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9239d945aa4f Added tag aarch64-jdk8u171-b10 for changeset bb1b68c7809e ! .hgtags Changeset: db0e0a17b29f Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/db0e0a17b29f Merge aarch64-jdk8u171-b10 ! .hgtags - src/share/classes/com/sun/crypto/provider/ai.java - test/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java - test/javax/management/remote/mandatory/connection/NewRMIClientFilterTest.java - test/javax/management/remote/mandatory/connection/mgmt1.properties - test/javax/management/remote/mandatory/connection/mgmt2.properties Changeset: 9fb782e334a9 Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9fb782e334a9 Added tag aarch64-shenandoah-jdk8u171-b10 for changeset db0e0a17b29f ! .hgtags From gnu.andrew at redhat.com Tue Apr 24 19:11:13 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 24 Apr 2018 19:11:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 3 new changesets Message-ID: <201804241911.w3OJBDp9008629@aojmv0008.oracle.com> Changeset: eb038e0fd088 Author: andrew Date: 2018-03-23 21:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/eb038e0fd088 Added tag aarch64-jdk8u171-b10 for changeset 31efd519fdb3 ! .hgtags Changeset: 11127e485615 Author: andrew Date: 2018-03-24 05:44 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/11127e485615 Merge aarch64-jdk8u171-b10 ! .hgtags Changeset: 4019790b0d49 Author: andrew Date: 2018-04-24 04:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/4019790b0d49 Added tag aarch64-shenandoah-jdk8u171-b10 for changeset 11127e485615 ! .hgtags From shade at redhat.com Wed Apr 25 07:35:11 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 25 Apr 2018 09:35:11 +0200 Subject: [aarch64-port-dev ] RFR: Fix new code for Shenandoah after the 8u171 merge Message-ID: Patch goes to: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot The patch itself should be self-obvious: # HG changeset patch # User shade # Date 1524641642 -7200 # Wed Apr 25 09:34:02 2018 +0200 # Node ID eaa8479dd1580fb4adec2327b5dd367787543a8c # Parent db8079be23d714b6ecca31a9f82136f1b29fe5d6 Fix new code for Shenandoah after the 8u171 merge diff -r db8079be23d7 -r eaa8479dd158 src/share/vm/prims/jvm.cpp --- a/src/share/vm/prims/jvm.cpp Tue Apr 24 04:31:20 2018 +0100 +++ b/src/share/vm/prims/jvm.cpp Wed Apr 25 09:34:02 2018 +0200 @@ -587,7 +587,7 @@ // If G1 is enabled then we need to register a non-null referent // with the SATB barrier. #if INCLUDE_ALL_GCS - if (UseG1GC) { + if (UseG1GC || UseShenandoahGC) { oop referent = java_lang_ref_Reference::referent(clone); if (referent != NULL) { G1SATBCardTableModRefBS::enqueue(referent); @@ -595,7 +595,7 @@ } #endif // INCLUDE_ALL_GCS if ((java_lang_ref_Reference::next(clone) != NULL) || - (java_lang_ref_Reference::queue(clone) == java_lang_ref_ReferenceQueue::ENQUEUED_queue())) { + (oopDesc::equals(java_lang_ref_Reference::queue(clone), java_lang_ref_ReferenceQueue::ENQUEUED_queue()))) { // If the source has been enqueued or is being enqueued, don't // register the clone with a queue. java_lang_ref_Reference::set_queue(clone, java_lang_ref_ReferenceQueue::NULL_queue()); Testing: hotspot_gc_shenandoah Thanks, -Aleksey From shade at redhat.com Wed Apr 25 07:35:56 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 25 Apr 2018 09:35:56 +0200 Subject: [aarch64-port-dev ] RFR [sh/8u]: Revert accidental OpSpinWait matching In-Reply-To: <9b28ee3f-9f6c-0d6a-331d-3a5f71b96071@redhat.com> References: <9b28ee3f-9f6c-0d6a-331d-3a5f71b96071@redhat.com> Message-ID: <1dc7b795-d869-f8e0-ddfa-9c1040df0018@redhat.com> Now that the merge came in, ping? -Aleksey On 03/22/2018 12:06 PM, Aleksey Shipilev wrote: > We have a weird difference between our sh/jdk8 development repo and aarch64-port-jdk8u-shenandoah > integration forest: it has a little branch that "matches" OpSpinWait, even though there is no such > node in 8u at all -- that feature came in JDK 9. This had accidentally leaked during previous merges. > > So, we want to push this to aarch64-port/jdk8u-shenandoah: > > diff -r 966a10251cb4 src/share/vm/adlc/formssel.cpp > --- a/src/share/vm/adlc/formssel.cpp Wed Mar 21 20:00:58 2018 +0000 > +++ b/src/share/vm/adlc/formssel.cpp Thu Mar 22 12:03:44 2018 +0100 > @@ -4066,8 +4066,7 @@ > !strcmp(_opType,"StoreFence") || > !strcmp(_opType,"MemBarVolatile") || > !strcmp(_opType,"MemBarCPUOrder") || > - !strcmp(_opType,"MemBarStoreStore") || > - !strcmp(_opType, "OnSpinWait"); > + !strcmp(_opType,"MemBarStoreStore"); > } > > bool MatchRule::is_ideal_loadPC() const { > > Testing: x86_64 build, hotspot_gc_shenandoah > > Thanks, > -Aleksey > From rkennke at redhat.com Wed Apr 25 08:18:00 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 25 Apr 2018 10:18:00 +0200 Subject: [aarch64-port-dev ] RFR: Fix new code for Shenandoah after the 8u171 merge In-Reply-To: References: Message-ID: Looks good to me. Thanks! Roman > Patch goes to: > http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot > > The patch itself should be self-obvious: > > # HG changeset patch > # User shade > # Date 1524641642 -7200 > # Wed Apr 25 09:34:02 2018 +0200 > # Node ID eaa8479dd1580fb4adec2327b5dd367787543a8c > # Parent db8079be23d714b6ecca31a9f82136f1b29fe5d6 > Fix new code for Shenandoah after the 8u171 merge > > diff -r db8079be23d7 -r eaa8479dd158 src/share/vm/prims/jvm.cpp > --- a/src/share/vm/prims/jvm.cpp Tue Apr 24 04:31:20 2018 +0100 > +++ b/src/share/vm/prims/jvm.cpp Wed Apr 25 09:34:02 2018 +0200 > @@ -587,7 +587,7 @@ > // If G1 is enabled then we need to register a non-null referent > // with the SATB barrier. > #if INCLUDE_ALL_GCS > - if (UseG1GC) { > + if (UseG1GC || UseShenandoahGC) { > oop referent = java_lang_ref_Reference::referent(clone); > if (referent != NULL) { > G1SATBCardTableModRefBS::enqueue(referent); > @@ -595,7 +595,7 @@ > } > #endif // INCLUDE_ALL_GCS > if ((java_lang_ref_Reference::next(clone) != NULL) || > - (java_lang_ref_Reference::queue(clone) == java_lang_ref_ReferenceQueue::ENQUEUED_queue())) { > + (oopDesc::equals(java_lang_ref_Reference::queue(clone), > java_lang_ref_ReferenceQueue::ENQUEUED_queue()))) { > // If the source has been enqueued or is being enqueued, don't > // register the clone with a queue. > java_lang_ref_Reference::set_queue(clone, java_lang_ref_ReferenceQueue::NULL_queue()); > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > From stuart.monteith at linaro.org Wed Apr 25 15:00:07 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 25 Apr 2018 16:00:07 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> Message-ID: Hello, The problem with C1 is in c1_CodeStubs_aarch64.cpp: RangeCheckStub::emit_code . There are two parameters being passed sometimes, with rscratch1 holding the index and rscratch2 holding a pointer to the array, sometimes. The issue is there is a far call, and to construct the pointer to jump to it is being passed rscratch2 to use as a temporary register: __ mov(rscratch2, _array->as_pointer_register()); then... __ far_call(RuntimeAddress(Runtime1::entry_for(stub_id)), NULL, rscratch2); By default rscratch1 is used as the temporary register. . I'm not quite sure to solve this yet - we'll need to use the stack in some safe way. BR, Stuart On 24 April 2018 at 13:27, Stuart Monteith wrote: > Hello Goetz, > It appears that it is just C1 that exhibits the problem - there has > been a delay as I've been investigating a hang in Java JDK running > some of my automation. > > I'll try and track down the issue. Otherwise, I do like the principle > of the patch. > > BR, > Stuart > > > On 24 April 2018 at 11:44, Lindenmaier, Goetz wrote: >> Hi Stuart, >> >> could you track down the remaining issue? >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >>> Sent: Donnerstag, 19. April 2018 17:09 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >>> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32-port- >>> dev at openjdk.java.net >>> Subject: Re: RFR(M): 8201593: Print array length in >>> ArrayIndexOutOfBoundsException. >>> >>> Hi, >>> I'm trying to work through what's going on here. With C1 not >>> crashing, I'll check the behaviour of the interpreter and C2. I'm >>> doing explicitly with -Xint, etc. WIth -Xint I definitely get the >>> error. >>> >>> You have the condition the wrong way round - >>> _throw_index_out_of_bounds_exception is true when array is NULL. >>> >>> >>> BR, >>> Stuart >>> >>> >>> On 19 April 2018 at 15:36, Lindenmaier, Goetz >>> wrote: >>> > Hi Stuart, >>> > >>> > thanks a lot for helping out here. >>> > I added below patch to my latest webrev (replaced it in-place): >>> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>> > >>> > The remaining problem looks like the array argument does not >>> > reach the method that prints the message properly. >>> > Did I get a register wrong? >>> > Did I use a wrong argument register, or does the untangling >>> > of registers in overwrite something? >>> > Is it correct to use mov and not movw in >>> templateInterpreterGenerator_aarch64.cpp? >>> > Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" here is >>> stupid, >>> > it seems to cause unnecessary register moves. But it's similar on all >>> platforms.) >>> > >>> > The test runs several times, assuring it's C1, C2 and Xint. >>> > This should help you to narrow down the problem. >>> > >>> > Best regards, >>> > Goetz. >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > diff -r 3fe33d48aa16 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp >>> > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 >>> 15:17:20 2018 +0200 >>> > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 >>> 16:06:23 2018 +0200 >>> > @@ -73,9 +73,10 @@ >>> > } else { >>> > __ mov(rscratch1, _index->as_jint()); >>> > } >>> > - __ mov(rscratch2, _array->as_pointer_register()); >>> > Runtime1::StubID stub_id; >>> > if (_throw_index_out_of_bounds_exception) { >>> > + assert(_array != NULL, "sanity"); >>> > + __ mov(rscratch2, _array->as_pointer_register()); >>> > stub_id = Runtime1::throw_index_exception_id; >>> > } else { >>> > stub_id = Runtime1::throw_range_check_failed_id; >>> > >>> > >>> > >>> > >>> >> -----Original Message----- >>> >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >>> >> Sent: Donnerstag, 19. April 2018 14:26 >>> >> To: Lindenmaier, Goetz >>> >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- >>> >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32- >>> port- >>> >> dev at openjdk.java.net >>> >> Subject: Re: RFR(M): 8201593: Print array length in >>> >> ArrayIndexOutOfBoundsException. >>> >> >>> >> Hello Goetz, >>> >> In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just >>> >> need to guard the emission of rscratch2 - you don't use it in one of >>> >> the cases, something like: >>> >> >>> >> if (!_throw_index_out_of_bounds_exception) { >>> >> __ mov(rscratch2, _array->as_pointer_register()); >>> >> } >>> >> >>> >> >>> >> Once I can run the unit tests, I'm seeing failures in your unit test like: >>> >> >>> >> java.lang.AssertionError: expected [trying to access index -5 of an >>> >> array with length 0] but found [trying to access index -5 of an array >>> >> with length -1459548190] >>> >> >>> >> >>> >> BR, >>> >> Stuart >>> >> >>> >> >>> >> On 18 April 2018 at 09:09, Lindenmaier, Goetz >>> >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > I would like to print a more verbose text on ArrayIndexOutOfBounds >>> >> exception >>> >> > that not only mentions the index, but also the length of the array >>> accessed. >>> >> > See the bug for documentation of the change of the message. >>> >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>> >> > >>> >> > @aarch/arm people: >>> >> > I edited the aarch/arm files. Could you please verify this is correct? >>> >> > I can not build on these platforms. >>> >> > >>> >> > The code on all the other platforms is tested with all the jtreg and jck >>> tests >>> >> etc. >>> >> > >>> >> > Best regards, >>> >> > Goetz. >>> >> > >>> >> > From goetz.lindenmaier at sap.com Wed Apr 25 15:17:31 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Apr 2018 15:17:31 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> Message-ID: <3b0ccb6fad574cf3bf47cfd19f527d05@sap.com> Hi Martin, Thanks for the review! I edited the comments and the one register as proposed. All makes sense. I also used LP64_ONLY etc, although I think it's got nothing to do with the length of data types, but with the architecture (which is expressed by ia32/amd64). New webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/04/ This also contains one fix for the windows build. The change is going into our tests tonight. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 24. April 2018 18:16 > To: Stuart Monteith ; Lindenmaier, Goetz > > Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; aarch32- > port-dev at openjdk.java.net > Subject: RE: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi G?tz, > > I've reviewed the platform code except aarch64/arm and I have some > requests for comment improvements. > > c1_CodeStubs_ppc: > - Remove comment "// pass in R0". > - Use std(index, -16, R1_SP). > > templateInterpreterGenerator_ppc.cpp: > - A comment would be good: "R4_ARG2 contains the array." > > interp_masm_sparc.cpp: > - Comment "move aberrant index into G3_scratch" needs update after > register change. > > templateInterpreterGenerator_sparc.cpp: > - Comment "index in register G3_scratch" ... "index to G4_scratch" is no > longer correct. Better would be "G3_scratch contains the array. Otos_i > contains the index." > > c1_Runtime1_x86: > - Better would be to pass num_arguments instead of bool has_argument, > but it works this way, too. At least the comment describing has_argument > should get fixed. > > templateInterpreterGenerator_x86.cpp: > - I think the comment "// Pass array to create more detailed exceptions." > should be in front of the rarg assignment. > > templateTable_x86.cpp > - I think LP64_ONLY + NOT_LP64 would be better than #ifdef IA32. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Stuart Monteith > Sent: Dienstag, 24. April 2018 14:28 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; aarch32- > port-dev at openjdk.java.net > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hello Goetz, > It appears that it is just C1 that exhibits the problem - there has > been a delay as I've been investigating a hang in Java JDK running > some of my automation. > > I'll try and track down the issue. Otherwise, I do like the principle > of the patch. > > BR, > Stuart > > > On 24 April 2018 at 11:44, Lindenmaier, Goetz > wrote: > > Hi Stuart, > > > > could you track down the remaining issue? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > >> Sent: Donnerstag, 19. April 2018 17:09 > >> To: Lindenmaier, Goetz > >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- > >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32- > port- > >> dev at openjdk.java.net > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi, > >> I'm trying to work through what's going on here. With C1 not > >> crashing, I'll check the behaviour of the interpreter and C2. I'm > >> doing explicitly with -Xint, etc. WIth -Xint I definitely get the > >> error. > >> > >> You have the condition the wrong way round - > >> _throw_index_out_of_bounds_exception is true when array is NULL. > >> > >> > >> BR, > >> Stuart > >> > >> > >> On 19 April 2018 at 15:36, Lindenmaier, Goetz > > >> wrote: > >> > Hi Stuart, > >> > > >> > thanks a lot for helping out here. > >> > I added below patch to my latest webrev (replaced it in-place): > >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >> > > >> > The remaining problem looks like the array argument does not > >> > reach the method that prints the message properly. > >> > Did I get a register wrong? > >> > Did I use a wrong argument register, or does the untangling > >> > of registers in overwrite something? > >> > Is it correct to use mov and not movw in > >> templateInterpreterGenerator_aarch64.cpp? > >> > Is it safe to use r3 in templateTable_aarch64.cpp? (The "convention" > here is > >> stupid, > >> > it seems to cause unnecessary register moves. But it's similar on all > >> platforms.) > >> > > >> > The test runs several times, assuring it's C1, C2 and Xint. > >> > This should help you to narrow down the problem. > >> > > >> > Best regards, > >> > Goetz. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > diff -r 3fe33d48aa16 > src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp > >> > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 > >> 15:17:20 2018 +0200 > >> > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 19 > >> 16:06:23 2018 +0200 > >> > @@ -73,9 +73,10 @@ > >> > } else { > >> > __ mov(rscratch1, _index->as_jint()); > >> > } > >> > - __ mov(rscratch2, _array->as_pointer_register()); > >> > Runtime1::StubID stub_id; > >> > if (_throw_index_out_of_bounds_exception) { > >> > + assert(_array != NULL, "sanity"); > >> > + __ mov(rscratch2, _array->as_pointer_register()); > >> > stub_id = Runtime1::throw_index_exception_id; > >> > } else { > >> > stub_id = Runtime1::throw_range_check_failed_id; > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > >> >> Sent: Donnerstag, 19. April 2018 14:26 > >> >> To: Lindenmaier, Goetz > >> >> Cc: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler- > >> >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; aarch32- > >> port- > >> >> dev at openjdk.java.net > >> >> Subject: Re: RFR(M): 8201593: Print array length in > >> >> ArrayIndexOutOfBoundsException. > >> >> > >> >> Hello Goetz, > >> >> In c1_CodeStubs_aarch64.cpp, RangeCheckStub::emit_code you just > >> >> need to guard the emission of rscratch2 - you don't use it in one of > >> >> the cases, something like: > >> >> > >> >> if (!_throw_index_out_of_bounds_exception) { > >> >> __ mov(rscratch2, _array->as_pointer_register()); > >> >> } > >> >> > >> >> > >> >> Once I can run the unit tests, I'm seeing failures in your unit test like: > >> >> > >> >> java.lang.AssertionError: expected [trying to access index -5 of an > >> >> array with length 0] but found [trying to access index -5 of an array > >> >> with length -1459548190] > >> >> > >> >> > >> >> BR, > >> >> Stuart > >> >> > >> >> > >> >> On 18 April 2018 at 09:09, Lindenmaier, Goetz > >> > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > I would like to print a more verbose text on ArrayIndexOutOfBounds > >> >> exception > >> >> > that not only mentions the index, but also the length of the array > >> accessed. > >> >> > See the bug for documentation of the change of the message. > >> >> > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >> >> > > >> >> > @aarch/arm people: > >> >> > I edited the aarch/arm files. Could you please verify this is correct? > >> >> > I can not build on these platforms. > >> >> > > >> >> > The code on all the other platforms is tested with all the jtreg and jck > >> tests > >> >> etc. > >> >> > > >> >> > Best regards, > >> >> > Goetz. > >> >> > > >> >> > From aph at redhat.com Wed Apr 25 15:26:22 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Apr 2018 16:26:22 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> Message-ID: <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> On 04/25/2018 04:00 PM, Stuart Monteith wrote: > I'm not quite sure to solve this yet - we'll need to use the stack in > some safe way. It's not a great idea to pass arguments in rscratch1 or rscratch2. These registers are for use in macros and should be treated as volatile. Given that you're throwing an exception, registers will be clobbered anyway. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Wed Apr 25 15:47:47 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Apr 2018 15:47:47 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> Message-ID: <22b95d9d1abe48b4bb92b980c498d745@sap.com> Hi, yes, on ppc for example we pass it on the stack. Before, it was passed in R0 which survives the call. That worked, as it obviously worked so far on aarch for the register with the index. Best regards, Goetz. > -----Original Message----- > From: aph at redhat.com [mailto:aph at redhat.com] > Sent: Mittwoch, 25. April 2018 17:26 > To: Stuart Monteith ; Lindenmaier, Goetz > > Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; aarch32- > port-dev at openjdk.java.net > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > On 04/25/2018 04:00 PM, Stuart Monteith wrote: > > I'm not quite sure to solve this yet - we'll need to use the stack in > > some safe way. > > It's not a great idea to pass arguments in rscratch1 or rscratch2. These > registers are for use in macros and should be treated as volatile. Given > that you're throwing an exception, registers will be clobbered anyway. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Wed Apr 25 15:49:10 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 25 Apr 2018 16:49:10 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> Message-ID: Indeed - and that is what I am seeing. Usually no parameters are being called with this pattern, or rscratch1, with the temporary variable being changed to use rscratch2 in such circumstances. I'll try c_rarg1 and c_rarg2 - they should pass straight through,if I interpret the code correcting. On 25 April 2018 at 16:26, Andrew Haley wrote: > On 04/25/2018 04:00 PM, Stuart Monteith wrote: >> I'm not quite sure to solve this yet - we'll need to use the stack in >> some safe way. > > It's not a great idea to pass arguments in rscratch1 or rscratch2. These > registers are for use in macros and should be treated as volatile. Given > that you're throwing an exception, registers will be clobbered anyway. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Thu Apr 26 10:51:41 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 26 Apr 2018 11:51:41 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> Message-ID: Hi, Using c_rarg1 and c_rarg2 instead of rscratch1 and overwriting rscratch2 causes a SIGSEGV. Using r22 and r23 instead, the test ran successfully. In c1_CodeStubs_aarch64.cpp : 77 if (_index->is_cpu_register()) { 78 __ mov(r22, _index->as_register()); 79 } else { 80 __ mov(r22, _index->as_jint()); 81 } 82 Runtime1::StubID stub_id; 83 if (_throw_index_out_of_bounds_exception) { 84 stub_id = Runtime1::throw_index_exception_id; 85 } else { 86 assert(_array != NULL, "sanity"); 87 __ mov(r23, _array->as_pointer_register()); 88 stub_id = Runtime1::throw_range_check_failed_id; 89 } in c1_Runtime_aarch64.cpp: 336 if (!has_argument) { 337 call_offset = __ call_RT(noreg, noreg, target); 338 } else { 339 call_offset = __ call_RT(noreg, noreg, target, r22, r23); 340 } There is the possibility of overwriting live values though, aren't there? The registers are saved by call_RT. Should I be concerned about deopt and debugging going wrong? Furthermore, won't there be issues in exception handlers? BR, Stuart On 25 April 2018 at 16:49, Stuart Monteith wrote: > Indeed - and that is what I am seeing. Usually no parameters are being > called with this pattern, or rscratch1, with the temporary variable > being changed to use rscratch2 in such circumstances. > I'll try c_rarg1 and c_rarg2 - they should pass straight through,if I > interpret the code correcting. > > On 25 April 2018 at 16:26, Andrew Haley wrote: >> On 04/25/2018 04:00 PM, Stuart Monteith wrote: >>> I'm not quite sure to solve this yet - we'll need to use the stack in >>> some safe way. >> >> It's not a great idea to pass arguments in rscratch1 or rscratch2. These >> registers are for use in macros and should be treated as volatile. Given >> that you're throwing an exception, registers will be clobbered anyway. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu Apr 26 14:14:44 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Apr 2018 14:14:44 +0000 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> Message-ID: <7767af56c6744e8aa5479a5dd9626936@sap.com> Hi Stuart, thanks for fixing this! Webrev with your changes: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/05/ > There is the possibility of overwriting live values though, aren't > there? The registers are saved by call_RT. Should I be concerned about > deopt and debugging going wrong? Furthermore, won't there be issues in > exception handlers? As I understand, this just has to survive the far_call. The call_RT in c1_Runtime then moves it into the proper argument registers. This is just the handling of an exception, and in these few instructions no java code is executed, no safepoint is passed, so this should be fine. incremental diff: iff -r 874f2b999ff6 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 26 15:55:18 2018 +0200 @@ -75,16 +75,16 @@ } if (_index->is_cpu_register()) { - __ mov(rscratch1, _index->as_register()); + __ mov(r22, _index->as_register()); } else { - __ mov(rscratch1, _index->as_jint()); + __ mov(r22, _index->as_jint()); } Runtime1::StubID stub_id; if (_throw_index_out_of_bounds_exception) { stub_id = Runtime1::throw_index_exception_id; } else { assert(_array != NULL, "sanity"); - __ mov(rscratch2, _array->as_pointer_register()); + __ mov(r23, _array->as_pointer_register()); stub_id = Runtime1::throw_range_check_failed_id; } __ far_call(RuntimeAddress(Runtime1::entry_for(stub_id)), NULL, rscratch2); diff -r 874f2b999ff6 src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp --- a/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 +++ b/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Thu Apr 26 15:55:18 2018 +0200 @@ -327,7 +327,7 @@ // target: the entry point of the method that creates and posts the exception oop -// has_argument: true if the exception needs an argument (passed in rscratch1) +// has_argument: true if the exception needs arguments (passed in r22 and r23) OopMapSet* Runtime1::generate_exception_throw(StubAssembler* sasm, address target, bool has_argument) { // make a frame and preserve the caller's caller-save registers @@ -336,7 +336,7 @@ if (!has_argument) { call_offset = __ call_RT(noreg, noreg, target); } else { - call_offset = __ call_RT(noreg, noreg, target, rscratch1, rscratch2); + call_offset = __ call_RT(noreg, noreg, target, r22, r23); } OopMapSet* oop_maps = new OopMapSet(); oop_maps->add_gc_map(call_offset, oop_map); Best regards, Goetz. > -----Original Message----- > From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > Sent: Donnerstag, 26. April 2018 12:52 > To: Andrew Haley > Cc: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; hotspot- > runtime-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi, > Using c_rarg1 and c_rarg2 instead of rscratch1 and overwriting > rscratch2 causes a SIGSEGV. > Using r22 and r23 instead, the test ran successfully. > > In c1_CodeStubs_aarch64.cpp > : > 77 if (_index->is_cpu_register()) { > 78 __ mov(r22, _index->as_register()); > 79 } else { > 80 __ mov(r22, _index->as_jint()); > 81 } > 82 Runtime1::StubID stub_id; > 83 if (_throw_index_out_of_bounds_exception) { > 84 stub_id = Runtime1::throw_index_exception_id; > 85 } else { > 86 assert(_array != NULL, "sanity"); > 87 __ mov(r23, _array->as_pointer_register()); > 88 stub_id = Runtime1::throw_range_check_failed_id; > 89 } > > in c1_Runtime_aarch64.cpp: > > 336 if (!has_argument) { > 337 call_offset = __ call_RT(noreg, noreg, target); > 338 } else { > 339 call_offset = __ call_RT(noreg, noreg, target, r22, r23); > 340 } > > There is the possibility of overwriting live values though, aren't > there? The registers are saved by call_RT. Should I be concerned about > deopt and debugging going wrong? Furthermore, won't there be issues in > exception handlers? > > BR, > Stuart > > > On 25 April 2018 at 16:49, Stuart Monteith > wrote: > > Indeed - and that is what I am seeing. Usually no parameters are being > > called with this pattern, or rscratch1, with the temporary variable > > being changed to use rscratch2 in such circumstances. > > I'll try c_rarg1 and c_rarg2 - they should pass straight through,if I > > interpret the code correcting. > > > > On 25 April 2018 at 16:26, Andrew Haley wrote: > >> On 04/25/2018 04:00 PM, Stuart Monteith wrote: > >>> I'm not quite sure to solve this yet - we'll need to use the stack in > >>> some safe way. > >> > >> It's not a great idea to pass arguments in rscratch1 or rscratch2. These > >> registers are for use in macros and should be treated as volatile. Given > >> that you're throwing an exception, registers will be clobbered anyway. > >> > >> -- > >> Andrew Haley > >> Java Platform Lead Engineer > >> Red Hat UK Ltd. > >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Thu Apr 26 14:31:38 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 26 Apr 2018 15:31:38 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <7767af56c6744e8aa5479a5dd9626936@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> <7767af56c6744e8aa5479a5dd9626936@sap.com> Message-ID: Thanks, I'm happy with that. The registers have a clean path to call_RT - r22 and r23 aren't used inbetween. They are an arbitrary choice - c_rarg0 and c_rarg1 were always going to cause problems. If _array->as_pointer_register() and/or _index->as_register() or _index->as_jint() were the registers we were using as parameters there would be trouble. However, with pd_last_allocatable_cpu_reg = 16, that shouldn't happen with r22/23, or indeed anything else in the range r17 to r28. I'm going to run all of JTRegs and seem what that produces now. BR, Stuart On 26 April 2018 at 15:14, Lindenmaier, Goetz wrote: > Hi Stuart, > > thanks for fixing this! Webrev with your changes: > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/05/ > >> There is the possibility of overwriting live values though, aren't >> there? The registers are saved by call_RT. Should I be concerned about >> deopt and debugging going wrong? Furthermore, won't there be issues in >> exception handlers? > As I understand, this just has to survive the far_call. > The call_RT in c1_Runtime then moves it into the > proper argument registers. This is just the handling of an > exception, and in these few instructions no java code is > executed, no safepoint is passed, so this should be fine. > > incremental diff: > iff -r 874f2b999ff6 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 26 15:55:18 2018 +0200 > @@ -75,16 +75,16 @@ > } > > if (_index->is_cpu_register()) { > - __ mov(rscratch1, _index->as_register()); > + __ mov(r22, _index->as_register()); > } else { > - __ mov(rscratch1, _index->as_jint()); > + __ mov(r22, _index->as_jint()); > } > Runtime1::StubID stub_id; > if (_throw_index_out_of_bounds_exception) { > stub_id = Runtime1::throw_index_exception_id; > } else { > assert(_array != NULL, "sanity"); > - __ mov(rscratch2, _array->as_pointer_register()); > + __ mov(r23, _array->as_pointer_register()); > stub_id = Runtime1::throw_range_check_failed_id; > } > __ far_call(RuntimeAddress(Runtime1::entry_for(stub_id)), NULL, rscratch2); > diff -r 874f2b999ff6 src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 > +++ b/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Thu Apr 26 15:55:18 2018 +0200 > @@ -327,7 +327,7 @@ > > > // target: the entry point of the method that creates and posts the exception oop > -// has_argument: true if the exception needs an argument (passed in rscratch1) > +// has_argument: true if the exception needs arguments (passed in r22 and r23) > > OopMapSet* Runtime1::generate_exception_throw(StubAssembler* sasm, address target, bool has_argument) { > // make a frame and preserve the caller's caller-save registers > @@ -336,7 +336,7 @@ > if (!has_argument) { > call_offset = __ call_RT(noreg, noreg, target); > } else { > - call_offset = __ call_RT(noreg, noreg, target, rscratch1, rscratch2); > + call_offset = __ call_RT(noreg, noreg, target, r22, r23); > } > OopMapSet* oop_maps = new OopMapSet(); > oop_maps->add_gc_map(call_offset, oop_map); > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> Sent: Donnerstag, 26. April 2018 12:52 >> To: Andrew Haley >> Cc: Lindenmaier, Goetz ; hotspot-compiler- >> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; hotspot- >> runtime-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi, >> Using c_rarg1 and c_rarg2 instead of rscratch1 and overwriting >> rscratch2 causes a SIGSEGV. >> Using r22 and r23 instead, the test ran successfully. >> >> In c1_CodeStubs_aarch64.cpp >> : >> 77 if (_index->is_cpu_register()) { >> 78 __ mov(r22, _index->as_register()); >> 79 } else { >> 80 __ mov(r22, _index->as_jint()); >> 81 } >> 82 Runtime1::StubID stub_id; >> 83 if (_throw_index_out_of_bounds_exception) { >> 84 stub_id = Runtime1::throw_index_exception_id; >> 85 } else { >> 86 assert(_array != NULL, "sanity"); >> 87 __ mov(r23, _array->as_pointer_register()); >> 88 stub_id = Runtime1::throw_range_check_failed_id; >> 89 } >> >> in c1_Runtime_aarch64.cpp: >> >> 336 if (!has_argument) { >> 337 call_offset = __ call_RT(noreg, noreg, target); >> 338 } else { >> 339 call_offset = __ call_RT(noreg, noreg, target, r22, r23); >> 340 } >> >> There is the possibility of overwriting live values though, aren't >> there? The registers are saved by call_RT. Should I be concerned about >> deopt and debugging going wrong? Furthermore, won't there be issues in >> exception handlers? >> >> BR, >> Stuart >> >> >> On 25 April 2018 at 16:49, Stuart Monteith >> wrote: >> > Indeed - and that is what I am seeing. Usually no parameters are being >> > called with this pattern, or rscratch1, with the temporary variable >> > being changed to use rscratch2 in such circumstances. >> > I'll try c_rarg1 and c_rarg2 - they should pass straight through,if I >> > interpret the code correcting. >> > >> > On 25 April 2018 at 16:26, Andrew Haley wrote: >> >> On 04/25/2018 04:00 PM, Stuart Monteith wrote: >> >>> I'm not quite sure to solve this yet - we'll need to use the stack in >> >>> some safe way. >> >> >> >> It's not a great idea to pass arguments in rscratch1 or rscratch2. These >> >> registers are for use in macros and should be treated as volatile. Given >> >> that you're throwing an exception, registers will be clobbered anyway. >> >> >> >> -- >> >> Andrew Haley >> >> Java Platform Lead Engineer >> >> Red Hat UK Ltd. >> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu Apr 26 15:16:26 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 26 Apr 2018 16:16:26 +0100 Subject: [aarch64-port-dev ] RFR: 8200556: AArch64: assertion failure in slowdebug builds In-Reply-To: <14959ca5-6c1f-6e87-a38e-017b7117ffcb@redhat.com> References: <94fb9efa-34ac-6668-ae2e-2e4bdbcdbf51@redhat.com> <14959ca5-6c1f-6e87-a38e-017b7117ffcb@redhat.com> Message-ID: On 24 April 2018 at 10:31, Andrew Dinn wrote: > On 23/04/18 19:36, Andrew Haley wrote: >> This is a rare assertion failure, debug builds only. >> >> http://cr.openjdk.java.net/~aph/8200556/ > > Looks good. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander I tagged this as jdk10u-fix-request and it's been approved. Ok for aarch64/jdk8u as well? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Thu Apr 26 15:50:05 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Apr 2018 16:50:05 +0100 Subject: [aarch64-port-dev ] RFR: 8200556: AArch64: assertion failure in slowdebug builds In-Reply-To: References: <94fb9efa-34ac-6668-ae2e-2e4bdbcdbf51@redhat.com> <14959ca5-6c1f-6e87-a38e-017b7117ffcb@redhat.com> Message-ID: On 04/26/2018 04:16 PM, Andrew Hughes wrote: > Ok for aarch64/jdk8u as well? Yes, please. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Ningsheng.Jian at arm.com Fri Apr 27 03:26:01 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian) Date: Fri, 27 Apr 2018 03:26:01 +0000 Subject: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option Message-ID: Hi, Please help to review this small fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8202186 Webrev: http://cr.openjdk.java.net/~njian/8202186/webrev.01/ JVM crashed, when I tried PrintC1Statistics option. It is caused by the literal address range limit of ldrw in incrementw. See JBS for the backtrace. Thanks, Ningsheng From aph at redhat.com Fri Apr 27 08:00:34 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Apr 2018 09:00:34 +0100 Subject: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option In-Reply-To: References: Message-ID: <1657c03e-011c-a223-3408-8f849305b681@redhat.com> On 04/27/2018 04:26 AM, Ningsheng Jian wrote: > Webrev: http://cr.openjdk.java.net/~njian/8202186/webrev.01/ Would a fix to incrementw be better? You'd have to check all of the callers. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Apr 27 08:04:31 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Apr 2018 09:04:31 +0100 Subject: [aarch64-port-dev ] RFR: 8200556: AArch64: assertion failure in slowdebug builds Message-ID: This is a rare assertion failure, debug builds only. http://cr.openjdk.java.net/~aph/8200556/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Ningsheng.Jian at arm.com Fri Apr 27 09:08:20 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian) Date: Fri, 27 Apr 2018 09:08:20 +0000 Subject: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option In-Reply-To: <1657c03e-011c-a223-3408-8f849305b681@redhat.com> References: <1657c03e-011c-a223-3408-8f849305b681@redhat.com> Message-ID: Hi Andrew, > -----Original Message----- > From: Andrew Haley > Sent: Friday, April 27, 2018 4:01 PM > To: Ningsheng Jian ; hotspot-compiler- > dev at openjdk.java.net > Cc: nd ; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes > with PrintC1Statistics option > > On 04/27/2018 04:26 AM, Ningsheng Jian wrote: > > Webrev: http://cr.openjdk.java.net/~njian/8202186/webrev.01/ > > Would a fix to incrementw be better? You'd have to check all of the callers. > I was thinking that the fix in incrementw may make this simple routine require two scratch registers. Current version is more flexible for user in register usage? What do you think? Thanks, Ningsheng From aph at redhat.com Fri Apr 27 13:24:17 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Apr 2018 14:24:17 +0100 Subject: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option In-Reply-To: References: <1657c03e-011c-a223-3408-8f849305b681@redhat.com> Message-ID: On 04/27/2018 10:08 AM, Ningsheng Jian wrote: > I was thinking that the fix in incrementw may make this simple routine require > two scratch registers. That's why you'd have to find check all of the callers. You could even pass the scratch registers in as arguments, for ease of maintenance. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Fri Apr 27 14:36:38 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 27 Apr 2018 15:36:38 +0100 Subject: [aarch64-port-dev ] RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <12e8ad2367484b0b88bcee4bcb77ac47@sap.com> <033adcb3-1ab0-094e-78cf-4062a8868d3e@redhat.com> <7767af56c6744e8aa5479a5dd9626936@sap.com> Message-ID: Hi, JTregs hasn't flagged any issues, so it should be ok. Regarding the 32-bit arm code, in "void RangeCheckStub::emit_code(LIR_Assembler* ce)" should: ce->verify_reserved_argument_area_size(1); be ce->verify_reserved_argument_area_size(2); so as to accommodate the array pointer you are pushing onto the stack? I've not tested 32-bit arm. BR, Stuart On 26 April 2018 at 15:31, Stuart Monteith wrote: > Thanks, I'm happy with that. > > The registers have a clean path to call_RT - r22 and r23 aren't used > inbetween. They are an arbitrary choice - c_rarg0 and c_rarg1 were > always going to cause problems. If _array->as_pointer_register() > and/or _index->as_register() or _index->as_jint() were the registers > we were using as parameters there would be trouble. However, with > pd_last_allocatable_cpu_reg = 16, that shouldn't happen with r22/23, > or indeed anything else in the range r17 to r28. > > I'm going to run all of JTRegs and seem what that produces now. > > BR, > Stuart > > > > > On 26 April 2018 at 15:14, Lindenmaier, Goetz wrote: >> Hi Stuart, >> >> thanks for fixing this! Webrev with your changes: >> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/05/ >> >>> There is the possibility of overwriting live values though, aren't >>> there? The registers are saved by call_RT. Should I be concerned about >>> deopt and debugging going wrong? Furthermore, won't there be issues in >>> exception handlers? >> As I understand, this just has to survive the far_call. >> The call_RT in c1_Runtime then moves it into the >> proper argument registers. This is just the handling of an >> exception, and in these few instructions no java code is >> executed, no safepoint is passed, so this should be fine. >> >> incremental diff: >> iff -r 874f2b999ff6 src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp >> --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 >> +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Apr 26 15:55:18 2018 +0200 >> @@ -75,16 +75,16 @@ >> } >> >> if (_index->is_cpu_register()) { >> - __ mov(rscratch1, _index->as_register()); >> + __ mov(r22, _index->as_register()); >> } else { >> - __ mov(rscratch1, _index->as_jint()); >> + __ mov(r22, _index->as_jint()); >> } >> Runtime1::StubID stub_id; >> if (_throw_index_out_of_bounds_exception) { >> stub_id = Runtime1::throw_index_exception_id; >> } else { >> assert(_array != NULL, "sanity"); >> - __ mov(rscratch2, _array->as_pointer_register()); >> + __ mov(r23, _array->as_pointer_register()); >> stub_id = Runtime1::throw_range_check_failed_id; >> } >> __ far_call(RuntimeAddress(Runtime1::entry_for(stub_id)), NULL, rscratch2); >> diff -r 874f2b999ff6 src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp >> --- a/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Mon Apr 16 15:17:20 2018 +0200 >> +++ b/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Thu Apr 26 15:55:18 2018 +0200 >> @@ -327,7 +327,7 @@ >> >> >> // target: the entry point of the method that creates and posts the exception oop >> -// has_argument: true if the exception needs an argument (passed in rscratch1) >> +// has_argument: true if the exception needs arguments (passed in r22 and r23) >> >> OopMapSet* Runtime1::generate_exception_throw(StubAssembler* sasm, address target, bool has_argument) { >> // make a frame and preserve the caller's caller-save registers >> @@ -336,7 +336,7 @@ >> if (!has_argument) { >> call_offset = __ call_RT(noreg, noreg, target); >> } else { >> - call_offset = __ call_RT(noreg, noreg, target, rscratch1, rscratch2); >> + call_offset = __ call_RT(noreg, noreg, target, r22, r23); >> } >> OopMapSet* oop_maps = new OopMapSet(); >> oop_maps->add_gc_map(call_offset, oop_map); >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >>> Sent: Donnerstag, 26. April 2018 12:52 >>> To: Andrew Haley >>> Cc: Lindenmaier, Goetz ; hotspot-compiler- >>> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; hotspot- >>> runtime-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8201593: Print array length in >>> ArrayIndexOutOfBoundsException. >>> >>> Hi, >>> Using c_rarg1 and c_rarg2 instead of rscratch1 and overwriting >>> rscratch2 causes a SIGSEGV. >>> Using r22 and r23 instead, the test ran successfully. >>> >>> In c1_CodeStubs_aarch64.cpp >>> : >>> 77 if (_index->is_cpu_register()) { >>> 78 __ mov(r22, _index->as_register()); >>> 79 } else { >>> 80 __ mov(r22, _index->as_jint()); >>> 81 } >>> 82 Runtime1::StubID stub_id; >>> 83 if (_throw_index_out_of_bounds_exception) { >>> 84 stub_id = Runtime1::throw_index_exception_id; >>> 85 } else { >>> 86 assert(_array != NULL, "sanity"); >>> 87 __ mov(r23, _array->as_pointer_register()); >>> 88 stub_id = Runtime1::throw_range_check_failed_id; >>> 89 } >>> >>> in c1_Runtime_aarch64.cpp: >>> >>> 336 if (!has_argument) { >>> 337 call_offset = __ call_RT(noreg, noreg, target); >>> 338 } else { >>> 339 call_offset = __ call_RT(noreg, noreg, target, r22, r23); >>> 340 } >>> >>> There is the possibility of overwriting live values though, aren't >>> there? The registers are saved by call_RT. Should I be concerned about >>> deopt and debugging going wrong? Furthermore, won't there be issues in >>> exception handlers? >>> >>> BR, >>> Stuart >>> >>> >>> On 25 April 2018 at 16:49, Stuart Monteith >>> wrote: >>> > Indeed - and that is what I am seeing. Usually no parameters are being >>> > called with this pattern, or rscratch1, with the temporary variable >>> > being changed to use rscratch2 in such circumstances. >>> > I'll try c_rarg1 and c_rarg2 - they should pass straight through,if I >>> > interpret the code correcting. >>> > >>> > On 25 April 2018 at 16:26, Andrew Haley wrote: >>> >> On 04/25/2018 04:00 PM, Stuart Monteith wrote: >>> >>> I'm not quite sure to solve this yet - we'll need to use the stack in >>> >>> some safe way. >>> >> >>> >> It's not a great idea to pass arguments in rscratch1 or rscratch2. These >>> >> registers are for use in macros and should be treated as volatile. Given >>> >> that you're throwing an exception, registers will be clobbered anyway. >>> >> >>> >> -- >>> >> Andrew Haley >>> >> Java Platform Lead Engineer >>> >> Red Hat UK Ltd. >>> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Ningsheng.Jian at arm.com Sat Apr 28 10:42:03 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian) Date: Sat, 28 Apr 2018 10:42:03 +0000 Subject: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option In-Reply-To: References: <1657c03e-011c-a223-3408-8f849305b681@redhat.com> Message-ID: Hi Andrew, > -----Original Message----- > From: Andrew Haley > Sent: Friday, April 27, 2018 9:24 PM > To: Ningsheng Jian ; hotspot-compiler- > dev at openjdk.java.net > Cc: nd ; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes > with PrintC1Statistics option > > On 04/27/2018 10:08 AM, Ningsheng Jian wrote: > > I was thinking that the fix in incrementw may make this simple routine > > require two scratch registers. > > That's why you'd have to find check all of the callers. You could even pass the > scratch registers in as arguments, for ease of maintenance. > Yes, I have checked and tested all the caller contexts. I forgot that original code would use two scratch registers, if incremented by a large value. Since strw does not support literal form, what about changing incrementw implementation like this? http://cr.openjdk.java.net/~njian/8202186/webrev.02/ Thanks, Ningsheng From dmitrij.pochepko at bell-sw.com Sat Apr 28 15:06:00 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Sat, 28 Apr 2018 18:06:00 +0300 Subject: [aarch64-port-dev ] RFR(S): 8202395: AARCH64: wrong encoding for SIMD instructions zip, trn, uzp Message-ID: <99d7e87b-ac6e-091a-7295-ccc5e28b753f@bell-sw.com> Hi, please review small patch for 8202395: AARCH64: wrong encoding for SIMD instructions zip, trn, uzp encoding for zip2, trn1, trn2, uzp1, uzp2 instructions was hardcoded as zip1 instruction(so, initially created opcode parameter wasn't used). This patch fix it. CR: https://bugs.openjdk.java.net/browse/JDK-8202395 webrev: http://cr.openjdk.java.net/~dpochepk/8202395/webrev.01/ testing: I've tested this patch with intrinsic(which found this bug) with zip2 instruction usage Thanks, Dmitrij From aph at redhat.com Sat Apr 28 16:35:28 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 28 Apr 2018 17:35:28 +0100 Subject: [aarch64-port-dev ] RFR 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option In-Reply-To: References: <1657c03e-011c-a223-3408-8f849305b681@redhat.com> Message-ID: On 04/28/2018 11:42 AM, Ningsheng Jian wrote: > Yes, I have checked and tested all the caller contexts. I forgot that original code > would use two scratch registers, if incremented by a large value. Since strw does not > support literal form, what about changing incrementw implementation like this? > > http://cr.openjdk.java.net/~njian/8202186/webrev.02/ That looks pretty good. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Sat Apr 28 18:29:09 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Sat, 28 Apr 2018 21:29:09 +0300 Subject: [aarch64-port-dev ] RFR: AARCH64: optimize string compare intrinsic Message-ID: <4b34bfad-8b91-68f3-36bc-7c488e54239e@bell-sw.com> Hi all, please review patch for? 8202326: AARCH64: optimize string compare intrinsic This patch introduces string compareTo stub, which uses large loops with prefetch instructions. Stub is called for long strings and improves String::compareTo up to 4 times on systems without hardware prefetching (ThunderX) and up to 2 times on systems with hardware prefetching (ThunderX2). Also inlined code is re-arranged with more optimal pipelining, which helps in-order systems, so small strings are also slightly improved. There are no noticeable regressions according to benchmark results. I created benchmark to measure improvement: http://cr.openjdk.java.net/~dpochepk/8202326/StringCompareBench.java Execution matrix is large and can be seen here: http://cr.openjdk.java.net/~dpochepk/8202326/str_compare.xls Raw results are *.txt files here: http://cr.openjdk.java.net/~dpochepk/8202326/ webrev: http://cr.openjdk.java.net/~dpochepk/8202326/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8202326 testing: I run jtreg hotspot tests: compiler/* gc/* runtime/* using fastdebug build and found no new failures. I also run long "bruteforce" test which checks all combinations of different character index for all strings up to size 512: http://cr.openjdk.java.net/~dpochepk/8202326/StrCmpTest.java Additional note: this patch depends on zip2 instruction encoding fix: JDK-8202395 Thanks, Dmitrij From aph at redhat.com Sun Apr 29 10:36:35 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 29 Apr 2018 11:36:35 +0100 Subject: [aarch64-port-dev ] RFR: AARCH64: optimize string compare intrinsic In-Reply-To: <4b34bfad-8b91-68f3-36bc-7c488e54239e@bell-sw.com> References: <4b34bfad-8b91-68f3-36bc-7c488e54239e@bell-sw.com> Message-ID: <5310674b-0e9d-8c30-233d-6a7b4ef54ac0@redhat.com> On 04/28/2018 07:29 PM, Dmitrij Pochepko wrote: > There are no noticeable regressions according to benchmark results. The speedup looks pretty convincing. What does the code size at call sites look like? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sun Apr 29 11:10:31 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 29 Apr 2018 12:10:31 +0100 Subject: [aarch64-port-dev ] RFR(S): 8202395: AARCH64: wrong encoding for SIMD instructions zip, trn, uzp In-Reply-To: <99d7e87b-ac6e-091a-7295-ccc5e28b753f@bell-sw.com> References: <99d7e87b-ac6e-091a-7295-ccc5e28b753f@bell-sw.com> Message-ID: <6ee17f2f-169e-0f98-83cb-4607c3a6ab82@redhat.com> On 04/28/2018 04:06 PM, Dmitrij Pochepko wrote: > please review small patch for 8202395: AARCH64: wrong encoding for SIMD > instructions zip, trn, uzp > > encoding for zip2, trn1, trn2, uzp1, uzp2 instructions was hardcoded as > zip1 instruction(so, initially created opcode parameter wasn't used). > This patch fix it. Oops. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Apr 30 08:27:45 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 30 Apr 2018 10:27:45 +0200 Subject: [aarch64-port-dev ] RFR: Fix new code for Shenandoah after the 8u171 merge In-Reply-To: References: Message-ID: Any other reviewers? Thanks, -Aleksey On 04/25/2018 10:18 AM, Roman Kennke wrote: > Looks good to me. > > Thanks! > Roman > > >> Patch goes to: >> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot >> >> The patch itself should be self-obvious: >> >> # HG changeset patch >> # User shade >> # Date 1524641642 -7200 >> # Wed Apr 25 09:34:02 2018 +0200 >> # Node ID eaa8479dd1580fb4adec2327b5dd367787543a8c >> # Parent db8079be23d714b6ecca31a9f82136f1b29fe5d6 >> Fix new code for Shenandoah after the 8u171 merge >> >> diff -r db8079be23d7 -r eaa8479dd158 src/share/vm/prims/jvm.cpp >> --- a/src/share/vm/prims/jvm.cpp Tue Apr 24 04:31:20 2018 +0100 >> +++ b/src/share/vm/prims/jvm.cpp Wed Apr 25 09:34:02 2018 +0200 >> @@ -587,7 +587,7 @@ >> // If G1 is enabled then we need to register a non-null referent >> // with the SATB barrier. >> #if INCLUDE_ALL_GCS >> - if (UseG1GC) { >> + if (UseG1GC || UseShenandoahGC) { >> oop referent = java_lang_ref_Reference::referent(clone); >> if (referent != NULL) { >> G1SATBCardTableModRefBS::enqueue(referent); >> @@ -595,7 +595,7 @@ >> } >> #endif // INCLUDE_ALL_GCS >> if ((java_lang_ref_Reference::next(clone) != NULL) || >> - (java_lang_ref_Reference::queue(clone) == java_lang_ref_ReferenceQueue::ENQUEUED_queue())) { >> + (oopDesc::equals(java_lang_ref_Reference::queue(clone), >> java_lang_ref_ReferenceQueue::ENQUEUED_queue()))) { >> // If the source has been enqueued or is being enqueued, don't >> // register the clone with a queue. >> java_lang_ref_Reference::set_queue(clone, java_lang_ref_ReferenceQueue::NULL_queue()); >> >> Testing: hotspot_gc_shenandoah >> >> Thanks, >> -Aleksey >> > > From shade at redhat.com Mon Apr 30 08:27:58 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 30 Apr 2018 10:27:58 +0200 Subject: [aarch64-port-dev ] RFR [sh/8u]: Revert accidental OpSpinWait matching In-Reply-To: <1dc7b795-d869-f8e0-ddfa-9c1040df0018@redhat.com> References: <9b28ee3f-9f6c-0d6a-331d-3a5f71b96071@redhat.com> <1dc7b795-d869-f8e0-ddfa-9c1040df0018@redhat.com> Message-ID: <087d6a63-9d33-e514-f050-512dbebc92f3@redhat.com> Ping. -Aleksey On 04/25/2018 09:35 AM, Aleksey Shipilev wrote: > Now that the merge came in, ping? > > -Aleksey > > On 03/22/2018 12:06 PM, Aleksey Shipilev wrote: >> We have a weird difference between our sh/jdk8 development repo and aarch64-port-jdk8u-shenandoah >> integration forest: it has a little branch that "matches" OpSpinWait, even though there is no such >> node in 8u at all -- that feature came in JDK 9. This had accidentally leaked during previous merges. >> >> So, we want to push this to aarch64-port/jdk8u-shenandoah: >> >> diff -r 966a10251cb4 src/share/vm/adlc/formssel.cpp >> --- a/src/share/vm/adlc/formssel.cpp Wed Mar 21 20:00:58 2018 +0000 >> +++ b/src/share/vm/adlc/formssel.cpp Thu Mar 22 12:03:44 2018 +0100 >> @@ -4066,8 +4066,7 @@ >> !strcmp(_opType,"StoreFence") || >> !strcmp(_opType,"MemBarVolatile") || >> !strcmp(_opType,"MemBarCPUOrder") || >> - !strcmp(_opType,"MemBarStoreStore") || >> - !strcmp(_opType, "OnSpinWait"); >> + !strcmp(_opType,"MemBarStoreStore"); >> } >> >> bool MatchRule::is_ideal_loadPC() const { >> >> Testing: x86_64 build, hotspot_gc_shenandoah >> >> Thanks, >> -Aleksey >> > > From rkennke at redhat.com Mon Apr 30 08:31:00 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 30 Apr 2018 10:31:00 +0200 Subject: [aarch64-port-dev ] RFR [sh/8u]: Revert accidental OpSpinWait matching In-Reply-To: <087d6a63-9d33-e514-f050-512dbebc92f3@redhat.com> References: <9b28ee3f-9f6c-0d6a-331d-3a5f71b96071@redhat.com> <1dc7b795-d869-f8e0-ddfa-9c1040df0018@redhat.com> <087d6a63-9d33-e514-f050-512dbebc92f3@redhat.com> Message-ID: <5F76A28C-4D8D-465D-919E-3019D8FA3DAF@redhat.com> Looks good to me. Am 30. April 2018 10:27:58 MESZ schrieb Aleksey Shipilev : >Ping. > >-Aleksey > >On 04/25/2018 09:35 AM, Aleksey Shipilev wrote: >> Now that the merge came in, ping? >> >> -Aleksey >> >> On 03/22/2018 12:06 PM, Aleksey Shipilev wrote: >>> We have a weird difference between our sh/jdk8 development repo and >aarch64-port-jdk8u-shenandoah >>> integration forest: it has a little branch that "matches" >OpSpinWait, even though there is no such >>> node in 8u at all -- that feature came in JDK 9. This had >accidentally leaked during previous merges. >>> >>> So, we want to push this to aarch64-port/jdk8u-shenandoah: >>> >>> diff -r 966a10251cb4 src/share/vm/adlc/formssel.cpp >>> --- a/src/share/vm/adlc/formssel.cpp Wed Mar 21 20:00:58 2018 +0000 >>> +++ b/src/share/vm/adlc/formssel.cpp Thu Mar 22 12:03:44 2018 +0100 >>> @@ -4066,8 +4066,7 @@ >>> !strcmp(_opType,"StoreFence") || >>> !strcmp(_opType,"MemBarVolatile") || >>> !strcmp(_opType,"MemBarCPUOrder") || >>> - !strcmp(_opType,"MemBarStoreStore") || >>> - !strcmp(_opType, "OnSpinWait"); >>> + !strcmp(_opType,"MemBarStoreStore"); >>> } >>> >>> bool MatchRule::is_ideal_loadPC() const { >>> >>> Testing: x86_64 build, hotspot_gc_shenandoah >>> >>> Thanks, >>> -Aleksey >>> >> >> -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From gnu.andrew at redhat.com Mon Apr 30 18:06:17 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:06:17 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u: Added tag aarch64-jdk8u171-b11 for changeset 58bf8f7f184d Message-ID: <201804301806.w3UI6HNi005297@aojmv0008.oracle.com> Changeset: a4b38fc93bc6 Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/rev/a4b38fc93bc6 Added tag aarch64-jdk8u171-b11 for changeset 58bf8f7f184d ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:06:25 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:06:25 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/corba: Added tag aarch64-jdk8u171-b11 for changeset e8d4f321311a Message-ID: <201804301806.w3UI6P82005388@aojmv0008.oracle.com> Changeset: 486cbe7a0fdf Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/486cbe7a0fdf Added tag aarch64-jdk8u171-b11 for changeset e8d4f321311a ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:06:32 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:06:32 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jaxp: Added tag aarch64-jdk8u171-b11 for changeset 0ecfb39b8cfd Message-ID: <201804301806.w3UI6WaC005514@aojmv0008.oracle.com> Changeset: 471381e0e181 Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/471381e0e181 Added tag aarch64-jdk8u171-b11 for changeset 0ecfb39b8cfd ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:06:40 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:06:40 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jaxws: Added tag aarch64-jdk8u171-b11 for changeset 7ffd685f5516 Message-ID: <201804301806.w3UI6eC7005648@aojmv0008.oracle.com> Changeset: 61a5375fb2a7 Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxws/rev/61a5375fb2a7 Added tag aarch64-jdk8u171-b11 for changeset 7ffd685f5516 ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:06:48 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:06:48 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/langtools: Added tag aarch64-jdk8u171-b11 for changeset 6c58348c39c2 Message-ID: <201804301806.w3UI6mEP005739@aojmv0008.oracle.com> Changeset: 31d92dd289ae Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/langtools/rev/31d92dd289ae Added tag aarch64-jdk8u171-b11 for changeset 6c58348c39c2 ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:06:56 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:06:56 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 2 new changesets Message-ID: <201804301806.w3UI6uEn005902@aojmv0008.oracle.com> Changeset: a08749f5c507 Author: aph Date: 2018-04-23 19:32 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/a08749f5c507 8200556: AArch64: assertion failure in slowdebug builds Reviewed-by: adinn ! src/cpu/aarch64/vm/nativeInst_aarch64.cpp Changeset: d590c8412437 Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/d590c8412437 Added tag aarch64-jdk8u171-b11 for changeset a08749f5c507 ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:07:05 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:07:05 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jdk: Added tag aarch64-jdk8u171-b11 for changeset 9239d945aa4f Message-ID: <201804301807.w3UI75pc006023@aojmv0008.oracle.com> Changeset: e52a344a24bb Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/e52a344a24bb Added tag aarch64-jdk8u171-b11 for changeset 9239d945aa4f ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:07:12 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 30 Apr 2018 18:07:12 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/nashorn: Added tag aarch64-jdk8u171-b11 for changeset eb038e0fd088 Message-ID: <201804301807.w3UI7CVn006128@aojmv0008.oracle.com> Changeset: 15fe65e06aa8 Author: andrew Date: 2018-04-30 19:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/nashorn/rev/15fe65e06aa8 Added tag aarch64-jdk8u171-b11 for changeset eb038e0fd088 ! .hgtags From gnu.andrew at redhat.com Mon Apr 30 18:14:16 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 30 Apr 2018 19:14:16 +0100 Subject: [aarch64-port-dev ] RFR: 8200556: AArch64: assertion failure in slowdebug builds In-Reply-To: References: <94fb9efa-34ac-6668-ae2e-2e4bdbcdbf51@redhat.com> <14959ca5-6c1f-6e87-a38e-017b7117ffcb@redhat.com> Message-ID: On 26 April 2018 at 16:50, Andrew Haley wrote: > On 04/26/2018 04:16 PM, Andrew Hughes wrote: >> Ok for aarch64/jdk8u as well? > > Yes, please. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 Thanks. Pushed and tagged as aarch64-jdk8u171-b11 http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/a08749f5c507 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From ashipile at redhat.com Mon Apr 30 17:58:29 2018 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 30 Apr 2018 17:58:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 2 new changesets Message-ID: <201804301758.w3UHwTt3001045@aojmv0008.oracle.com> Changeset: eaa8479dd158 Author: shade Date: 2018-04-25 09:34 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eaa8479dd158 Fix new code for Shenandoah after the 8u171 merge ! src/share/vm/prims/jvm.cpp Changeset: c644bca00126 Author: shade Date: 2018-04-30 16:10 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c644bca00126 Revert accidental OpSpinWait matching ! src/share/vm/adlc/formssel.cpp From paul.sandoz at oracle.com Mon Apr 30 22:21:15 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 15:21:15 -0700 Subject: [aarch64-port-dev ] RFR: AARCH64: optimize string compare intrinsic In-Reply-To: <4b34bfad-8b91-68f3-36bc-7c488e54239e@bell-sw.com> References: <4b34bfad-8b91-68f3-36bc-7c488e54239e@bell-sw.com> Message-ID: Hi Dmitrij, Here is a somewhat lateral thought, it might have some legs... For the case when the encoding of the compared strings are the same have you considered changing the string compare implementations to use the array mismatch functionality (see jdk.internal.util.ArraysSupport.vectorizedMismatch) and then optimize that for AARCH64, if not already done so. It may simplify things in some respects but it would also broaden the performance impact to arrays and buffers. Paul. > On Apr 28, 2018, at 11:29 AM, Dmitrij Pochepko wrote: > > > > Hi all, > > please review patch for 8202326: AARCH64: optimize string compare intrinsic > > This patch introduces string compareTo stub, which uses large loops with prefetch instructions. Stub is called for long strings and improves String::compareTo up to 4 times on systems without hardware prefetching (ThunderX) and up to 2 times on systems with hardware prefetching (ThunderX2). Also inlined code is re-arranged with more optimal pipelining, which helps in-order systems, so small strings are also slightly improved. > There are no noticeable regressions according to benchmark results. > > I created benchmark to measure improvement: http://cr.openjdk.java.net/~dpochepk/8202326/StringCompareBench.java > > Execution matrix is large and can be seen here: http://cr.openjdk.java.net/~dpochepk/8202326/str_compare.xls > > Raw results are *.txt files here: http://cr.openjdk.java.net/~dpochepk/8202326/ > > webrev: http://cr.openjdk.java.net/~dpochepk/8202326/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8202326 > > testing: I run jtreg hotspot tests: compiler/* gc/* runtime/* using fastdebug build and found no new failures. I also run long "bruteforce" test which checks all combinations of different character index for all strings up to size 512: http://cr.openjdk.java.net/~dpochepk/8202326/StrCmpTest.java > > > Additional note: this patch depends on zip2 instruction encoding fix: JDK-8202395 > > Thanks, > > Dmitrij >